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PREFACE 


This book is intended for product developers, system programmers, and others who need detailed 
information about Systems Network Architecture (SNA) type 2.1 nodes in order to develop a prod- 
uct or program that implements the architecture. 


This book does not describe any specific machines or programs that may implement SNA, nor does 
it describe any implementation-specific subsets or deviations from the architectural description 
that may appear within any IBM SNA product. These matters, as well as information on SNA prod- 
uct installation and system definition, are described in the appropriate publications for the 
particular IBM SNA machines or programs to be used. 


The following books should be read in conjunction with this one. 


PREREQUISITE PUBLICATIONS 


SNA Concepts and Products, 6C30-3072—basic information on SNA for those readers wanting 
either an overview or a foundation for further study. 


SNA Technical Overview, 6C30-3073—additional details on SNA, especially on functions and 
control sequences; bridges the gap between the most elementary overview of SNA and the 
detailed descriptions of the formats and protocols. 


RELATED PUBLICATIONS 


SNA Format and Protocol Reference Manual: Architectural Logic, SC30-3112—comprehensive 
information on the formats and protocols of SNA nodes; includes information on the formats 
and protocols used by type 2.0 nodes in attaching to SNA subarea networks. Type 2.0 and 


type 2.1 nodes appear the same to the subarea network. 


SNA Reference Summary, GA27-3136—detailed information on SNA formats. 


SNA Format and Protocol Reference Manual: Architecture Logic for L Type 6.2> 
$C30-3269—reference information on SNA formats and protocols for LU type 6.2. 


SNA—Sessions Between Logical Units, 6C20-1868—reference information on SNA formats and 
protocols for LU types other than type 6.2. 


IBM SOLC Concepts,» GA27-3093—supplementary details of Synchronous Data Link Control. 


IBM Token-Ring Network Architecture Reference, publication number 6165877, available through 
product centers—details of IBM Token-Ring Network architecture. 
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tion Manual, GA27-3345—overviem and details of IBM's support for the CCITT 1980 X.25 recom- 
mendation. 
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Information Manual, GA27-376l—overview of IBM's support for the CCITT 1984 X.25 recommenda- 
tion. | 
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CHAPTER 1. 


T2.1 NODE OVERVIEW 


USE AND ORGANIZATION OF THIS BOOK 


This book, in conjunction with the companion 
books listed in the Preface, provides a 
formal definition of a Systems Network Archi- 


tecture (SNA) type 2.1 node (hereafter 
referred to as a T2.1 node). This book 
describes only the peer communications 


between T2.1 nodes. For details of communi- 
cation between T2.1 nodes and subarea net- 
works » see the 7T2.0 node. architecture 
described in SNA Format and Protocol Refer- 
ence Manual: Architectural Logic. 

The T2.1 node is described in the form of a 
functionally layered system that is decom- 


TERMS AND CONCEPTS 


OVERVIEW 


Exchange Identification (XID) 


A basic link unit (BLU) that is used to con- 
vey node and link characteristics to an adja- 
cent node is referred to as an Exchange 
Identification (XID) BLU, or more simply, an 
XID. XIDS are exchanged between link 
stations before and during link activation to 
establish and negotiate link and node charac- 
teristics, and after link activation to com- 
municate changes in these characteristics. 
"Exchange Identification (XID) Information 
Fields” in Appendix B gives format details. 


See "Chapter 2. Configuration Services" for 
details of XID exchange and negottation. 


Link 


A link is the combination of the link con- 
nection (the transmission medium) and tuo 
link stations, one at each end of the link 
connection. <A link connection can be shared 


among multiple links in a multipoint config- . 


uration. 


OF T2.1 NODE FUNCTION 


The T2.1 node allows peer-to-peer connection — 


of distributed processors, and provides the 


posed into components. These components are 
described via text, block diagrams, and 
finite-state machines (FSMs). 


The remainder of this chapter first presents 
key terms and concepts for T2.1 nodes» and 
then provides a high-level overvien of the 
node's function and components. Chapters 2, 
3, and 4 present more details. Appendixes A,» 
B, and C contain, respectively, information 
on FSM notation and concepts, relevant for- 
mats, and the abbreviations (on fold-out 
pages) used in this document. 


Address Spaces 


For each adjacent link station (ALS) to which 
a T2.1 node can send message units, a sepa- 
rate path control instance and corresponding 
address space of local-form session identifi- 
ers is maintained. Each path control 
instance handles addresses only from tts cor- 
responding address space. 


Local-Form Session Identifier (LFSID) 


T2.1 nodes associate «ach session using a 
given link with a 17-bit local-form session 
identifier (LFSID) taken from the address 
Space corresponding to that link. 


See "Chapter 4. Path Control" for a dis-~- 
cussion of how the LFSID 1s encoded in the 


ODAI, OAF', and DAF' fields of the FID2 
transmission header (TH). "Chapter 3. 
Address Space Manager" discusses the 


LFSID-assignment algorithm. 


physical and session-level connectivity 
required for support of LU 6.2, hereafter 
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Figure 


referred to as the LU.! Figure 1-1 on page 
1-2 shows the basic peer connection of T2.1 
nodes. 


Tei 
Node 


Tos 
Node / 


1-1. Node A Attached to Node B by a Link 
DATA LINK CONTROL 


The data link control (DLC) used betpeen tno 
T2.1 nodes may be any one of a number of sup- 
ported DLCs, e.g.» IBM token-ring, X.25,5 or 
SDLC.’ A T2.1 node may function as either the 
primary or secondary station on the link. 
The link station role, along with other 
detatls of the link-level communication, may 
be negotiated during the initial link-level 
contact, thereby reducing system-definition 
requirements for interconnecting T2.1 nodes. 


T2.1 nodes exchange XID format 3 (XID3) BLUs 
to perform role negotiation. Information 


about the sending node's characteristics is 


_ aa ae 


Figure 1-2. 


A T2.1 Node with Multiple Links 


In Figure 1-2, node A has two links, allowing 
it to communicate concurrently with nodes B 
and C. 


Communication between nodes B and C can be 
provided through an application-level func- 
tion in node A. | 


SESSION CAPABILITIES 


T2.1 nodes support LUs that can both initiate 
sessions and respond to session initiation 
requests; a T2.1 node LU is capable of send- 
ing and receiving BINDs. The BIND sender is 


1 Currently, LU 6.2 is the only LU supported. 


contained in the XID3, including link station 
role (primary, secondary, or negotiable), 
node type, FID type supported on the link, 
and maximum basic transmission unit (BTU) 
size that can be received. "Chapter 2. Con- 
figuration Services" describes role negoti- 
ation. 


MULTIPLE LINKS 


Activation of multiple links from a T2.1 node 
to more than one adjacent T2.1 node is also 
supported. Figure 1-2 illustrates an example 
of this. 3 


referred to as the primary LU (PLU); the BIND 
receiver is referred to as the secondary LU 
(SLU). | 


As showm in Figure 1-3 on page 1-3, multiple 
and parallel sessions may be established by 
an LU. In the figure, LU X supports parallel 
sessions with LU Y and a single session with 
LU Z. 


The direction of the session arrows shows the 
PLU-SLU relationship; in this example, LU X 
acts as the PLU for the session with LU Z and 
one of the sessions with LU Y. LU X also 
acts as the SLU for one of the parallel ses- 
Sions conducted with LU Y. 
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, EE 
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Key 
~/- represents a link between nodes 
— represents a session between LUs 


Figure 1-3. Session Capabilities 


T2.1 nodes exchange BINO and RSP(BIND) for 
session initiation, and UNBIND and 
RSP(UNBIND) for session termination. The 
BINDs may flow in either direction between 
tuo T2.1 nodes at any time after the initial 
link-level contact. An UNBIND may be sent by 
either LU. 


No request/response units (RUs) other than 
BIND, UNBIND, RSP(BIND), and RSP(UNBIND) are 
required by the T2.1 node for session initti- 
ation and termination. 


TRANSMISSION HEADER USAGE 


T2.1 nodes use the 6-byte FID2 TH to transmit 
all RUs. The LFSID (see "Terms and Con- 
cepts"), along with a path control instance 
identifier (within the node), is used to 


identify the particular session on which an 


RU is flowing. All other fields in the TH 
are used as defined for the type 2.0 node. 


See SNA Reference Summary for format details 
of the FID2 TH. 


REDUCTION OF SYSTEM DEFINITION 


Peer-commected T2.1 nodes have fewer 
system-definition requirements than other 
nodes. They do not require pre-assigned ses- 
ston addresses, and ACTLU and ACTPU are not 
required from an external system. Link sta- 
tion roles can be negotiated rather than 
assigned at system-definition time. 
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Figure 1-4. First-Level Decomposition of a T2.1 Node 


OVERVIEW OF T2.1 NODE COMPONENTS 


cae Ce 0 EEE 


A T2.1 node consists of the components shorn data link control (DLC). An overview of 
in Figure 1-4: node operator facility (NOF); these components is provided in the following 
control point (CP); and multiple instances of | sections. 


logical unit (LU), path control (PC), and 
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NODE OPERATOR FACILITY (NOF) 


NOF's function is to communicate with the CP 
operator, pass on the operator commands to 
CP, and initialize the CP components at IPL 
time. NOF manages requests for such func- 
tions as updating and querying CP data bases, 
activating and deactivating LUs, and activat- 
ing and deactivating links. 


Session 
Services 


Configuration 
Services 


Figure 1-5. Structure of Control Point 


CONTROL POINT (CP) 


CP's major function is to manage the 
resources of the T2.1 node. It creates the 
PC and DLC instances,» directs such link-level 
functions as link activation and deacti- 
vation, and assists LUs in session initiation 
and termination. 


LOGICAL UNIT (LU) 


A logical unit serves as a port into the net-~ 
work for one or more application transaction 
programs. 


Consult 
Manual: Architecture Logic for LU Type 6.2 
for more details on LU 6.2. 


e 

e 

e 

e 

e 

Address e 
Space e 
Manager bd 
e 

e 

A Control e 
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The session initiation function requires a 
directory for the mapping of a destination LU 
name to its corresponding CP name, and to the 
specific link used to access the node con- 
taining that CP. Every node has its own con- 
trol point and is responsible for maintaining 
its own error log. 


Within the CP component, three subcomponents 
exist. These subcomponents—session services 
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(SS), configuration services (CS), and 
address space manager (ASM)—and their commu- 
nication paths with other components are 
showmm in Figure 1-5 on page 1-5. The 
sections below provide overview information 
for each of these subcomponents. Since CS 
and ASM constitute a major portion of the CP 
function, "Chapter 2. Configuration Services" 
and "Chapter 3. Address Space Manager" have 
been devoted to a detailed treatment of their 
functions. 


Session Services (SS) 


SS assists LUs with session initiation by 


providing the following services: 


e Maintaining a directory that maps a des- 
‘tination LU name to its corresponding CP 
name and Link. 


e Checking with CS that the required link 
is activated and, if not, requesting that 
CS activate the link. 


® Providing the LU with the path control 
instance identifier that is associated 
with the required link. 


SS also assists with session-termination 
processing. A local LU notifies SS whenever 
one of its sessions terminates. If SS deter- 
mines that no sessions are using a link, it 
notifies CS so that the link can be deacti- 
vated. 


In this book, LU communications with SS are 
modeled using a direct protocol boundary, 
rather than via a session as in previous SNA 
books. 


Configuration Services (CS) 


CS manages the local links attached to the 
node and provides the following services: 


e Link activation: Upon request from the 
CP operator (via NOF) or SS, a specified 
link is activated. This includes 
exchanging XIDs and. negotiating the XID 
values (e.g., primary-secondary Link sta- 
tion roles). 


° Link deactivation: Upon request from the 
CP operator (via NOF) or SS, a specified 
link is deactivated. 


® Link failure processing: When a link 
connection or link = station failure 
occurs, appropriate cleanup and notifica- 
tion of ASM is performed. 


Address Space Manager (ASM) 


ASM manages all LFSIDs used by the node. Its 
functions are: 


® Node address control 


- Activate and deactivate address 


spaces 


- Assign and free LFSIDs for each 
address space 


- Maintain the relationship between 
LFSIDs in use and the LUs to which 
they are assigned 


* Sesston-control initiation and = termi- 
nation message routing | 


- Route session-control initiation and 
termination basic information units 
(BIUs) between LUs and path control 
instances (BIND, RSP(BIND), UNBIND, 
RSP( UNBIND ) ) 


e® Notify LUs when a link connection or link 
station failure occurs 


ASM performs the session address assignment 
and routing function that was done by the 
nodal NAU manager in the LU 6.2 
meta-tmplementation. (See SNA Format and 
Protocol Reference Manual: Architecture Log- 


ic for LU Type 6.2 for details.) 


PATH CONTROL (PC) 


PC delivers message units between LUs in the 
same or different nodes and allows LUs to 
exchange message units without concern for 
the umderlytng Link characteristics. Path 
control routes message units between DLCs and 
LUs. It also performs segnent generation and 
reassembly (1 supported) and error checking 
on message units received from DLC. 


"Chapter 4. Path Control" provides a more 
detailed discussion of path control. 


DATA LINK CONTROL (DLC) 


DLC provides the protocols necessary for 
reliable delivery of BTUs between paired link 
stations in nodes attached to a common link 
connection. DLC also controls the node 
attachment to various types of transmission 
facilities (e.g., switched facilities). It 
is the only component that communicates 
directly with the transmission medium. 


In this book, each link connection is repres- 
ented by a DLC instance consisting of a DLC 
manager and element. The element contains 
either one secondary link station, or one or 
more (in the case of a multipotnt link con- 
nection) primary link stations. 
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CHAPTER 


2. CONFIGURATION SERVICES 


INTRODUCTION 


The configuration services (CS) component of 
a T2.1 node activates and deactivates links 
to adjacent nodes, as well as managing those 
links. It provides information acquired as a 
result of its link management functions to 
the other components of the node. 


This introductory section presents an over- 
view of the flows ona link. Later sections 


provide considerations for the data base 
maintained by CS, greater detail on the dif- 
ferent stages of the link flows (link acti- 
vation, nonactivation exchange » link 
deactivation), a detailed presentation of XID 
format 3 (XID3) as used by T2.1 nodes,» and, 
finally, certain finite-state machines (FSMs) 
used by CS. 
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The exchanges showm during link activation may be sent asynchronously by either node, 


depending on the type of DLC; they are shomm here without crossings or duplication (e.g., both 


nodes sending a null XID) tn order to simplify the diagram. 


ESI is the Exchange State indicators 


field discussed in "Rules for Sequencing XIDs" on page 2-7. 


Figure 2-1. Overview of CS Link Protocols 
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CS OVERVIEW 


Figure 2-1 outlines the flows on the link 
between two T2.1 nodes,» A and B. Optional 
flows, as for instance the "dial' sequence 
initiated by node A, are marked with double 
brackets. The single braces to the right of 
the picture indicate the terms applied to 
various groupings of flows. The sections 
below define the terms and groupings used in 
the diagram. 


Link Activation 


Link activation encompasses the activation of 
the physical link connection and the link 
stations. It ts comparable to the procedures 
executed as a result of the ACTLINK and CON- 
TACT commands tn the subarea environment, and 
1S composed of up to three phases: 


® Connect phase 
¢ Prenegotiation XID exchange 
e Contact phase 


The connect phase allows initial establish- 
ment of communication betpreen nodes. 'Dial" 
and "answer" establish physical layer con- 
nection on smitched facilities, and may be 
between modems, on the IBM Token Ring» or 
over X.25 networks. "Equalization" is the 
transmission of training sequences’ that 
eccurs between trio modems (see ''NModem Equal- 
ization'' on page 2-6 for further details). 
Once the connect phase has completed, the two 
nodes are able to exchange and establish node 
characteristics via XID commands. (Compara- 
ble flows exist for the IBM token ring archi- 
tecture; see IBM Token-Ring Network 
Architecture Reference for details.) As 
indicated in Figure 2-1 on page 2-2 by double 
brackets, the connect phase and prenegoti- 
ation XID exchange are optional flows, based 
on the characteristics of the link connection 
and link stations. 


A null XID is an XID with an I-field of zero 
length, and is used to "poll" an adjacent 
node. Polling is performed in order to 
determine if the adjacent link station is 
active; a null XID may be used when the poll- 
ing node does not Know that the polled node 
is a T2.1 node, i.e., that it can accept an 
XID3 poll. 


During this initial link-activation XID 
exchange, before link station roles have been 
determined, the link station roles may be 
primary, secendary, or negotiable.! Primary 
or negotiable stations may send a null XID. 
Node B, recetving a null XID, responds with 


an XID3 whose Exchange State indicators field 
(ESI) 1s set to 'Prenegotiation" or "Negoti- 
ation Proceeding." 


Node A may elect to send a prenegotiation 
XID3, without a prior null XID, if it is 
Known that node B is able to accept an XID3. 
With or without a null XID, the optional pre- 
negotiation exchange 1s concluded after both 
nodes have sent and received a prenegotiation 
XID3; the prenegotiation exchange may also be 
concluded by the receipt of a 
negotiation-proceeding XID3 in response to a 
prenegotiation XID3, as described in "Negoti- 
ation XID Exchange" on page 2-8. 


XID3 negotiation is performed by T2.1 nodes 
to establish the primary and secondary roles 
of the link stations, as well as other char- 
acteristics of the link. (See "Negotiation 
XID Exchange" on page 2-8 for details of XID3 
negotiation. ) The primary-secondary role 
determines which link station will have con- 
trol of the link, and is also used in setting 
the value of the ODAI bit in the LFSID (see 
"Chapter 3. Address Space Manager"). 


The negotiation-proceeding XID exchange fin- 
ishes when link station roles have been 
established as complementary, 1.e., one link 
station 1s primary and the other 1s second- 
ary. The primary link station sends the 
mode-setting command. 


Once the wmode-setting command and UA have 
been sent, and RR or RNR has flowed on the 
link, the contact and link activation phases 
are complete. 


Nonactivation XID Exchange 


A nonactivation XID is an XID3 that is sent 
after the contact phase has completed. Its 
purpose is to communicate changes in the 
characteristics of a link or node. The non- 
activation XID3 exchange is currently initi- 
ated only by the primary) link station. 
Nonactivation exchanges are discussed in 
greater detail in "Nonactivation XID 
Exchange" on page 2-9. 


Link Deactivation 


Link deactivation can be initiated by either 
link station (by the primary saith the SDOLC 
Disconnect command or by the secondary with 
the Request Disconnect command) and breaks 
the connection between the two link stations. 
The final "on hook" indicates the termination 
of a switched link connection. 


Primary and secondary link station roles for asynchronous balanced mode (ABM) and ABM 


extended (ABME) stations have no relevance beyond determining which station will send the 
mode-setting command and how the ODAI bit is set. Considerations for ABM and ABME link 
Stations are discussed in "ABM Support Indicator" on page 2-12. | 
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Figure 


A node is responsible for its ow local defi- 
nition of supported LUs, links and their 
characteristics, node capabilities, and the 
CP names of nodes that can be directly 


Node Node 


2-2. Node A Attached to Node B by a Link 


In order for LUs at Node A to commmicate 
with LUs at node B, as shown in Figure 2-2, 
the following information is required at node 
A: 


® Link to node B 
e Names of LUs contained at node B 


as well as the information below, at node B: 
e Link to node A 

e Names of LUs contained at node A 

SYSTEM DEFINITION OF A LINK 

A node requires the following system defi- 
nition for a local link station: 


° Link station role: 
or negotiable 


primary, secondary, 


e Link station address for any local sec- 


ondary or negotiable station 
® Modem equalization delay value 
° Inactivity timer 
¢  Mode-setting command retry limit 


In addition, a unique ALS name must be pro- 


vided for each ALS that can be contacted by — 


the local link station. 


Certain nodes not at the current level? of 
SNA can act only as primary link stations 
iswitched or non-switched) and require the 
attaching node to always assume the secondary 
role (never negotiable or primary). The 
requirement that the attaching node must be 
secondary 1s defined by the network installa- 
tion manager at system definition time in the 
attaching node. 


Where modem equalization is required on a 
switched link connection, it must be possible 
at system definition, or no later than link 


activation time, for the network installation 


manager to identify any adjacent node that 
does not delay initial transmission of the 


2 


. through 


attached; this information is maintained by 
the CS component in a data base for use by 
other components of the node. 


XID as a called party. "Modem Equalization" 
on page 2-6 provides a more detailed dis- 
cussion of this topic. 


SYSTEM DEFINITION FOR NONSNITCHED LINK CON- 
NECTIONS. 


Nonswitched link connections can be either 
point-to-point or multipoint. Implementa- 
tions may provide the ability to add second- 
ary link stations to existing nonswitched 
point-to-point or multipoint link connections 
dynamic reconfiguration. 
Point-to-point link connections that can be 
changed to multipoint link connections in 
this manner are called multipoint-capable 
link connections. 


Coordinated system definition of link station 
roles and secondary link station addresses is 
required for operation on a multipoint or a 
multipoint-capable link connection. For such 
connections, the following restrictions on 
link station roles are defined: 


® One and only one primary link station 
exists on the link connection. 


® One or more secondary link stations exist 
on the link connection. 


e =€68No negotiable stations may exist on the 
connection. 


Negotiable stations are not usable on multi- 
point or multipoint-capable link connections; 
this is because negotiable stations use the 
broadcast address to avoid defining the sec- 
ondary address when they do not Know which 
will be the secondary station. Therefore, if 
a negotiable station 1s used on a nonswitched 
point-to-point Link connection, the link con- 
nection is not multipoint-capable and no 
additional link stations may be added to the 
link connection through dynamic reconfigura- 
tion. | 


The predefined primary station on a multi- 
point or ao multipoint-capable nonswitched 
link connection must be provided information 


"Current level" means as defined in this edition of the architectural specification. 
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about each secondary station on the link con- 
nection. The following system definition 
information must be provided at the primary 
station to define an adjacent link station: 


e Secondary station address. The primary 
station must use a specific secondary 
station addresses. It cannot use the 
broadcast address oon multipoint = or 
multipoint-capable link comections 
because it would cause multiple secondary 
stations to respond simultaneously. 


e XID type (optional). This information 
defines the XID format to be used sihen 
activating the link. It need not be pro- 
vided if all link stations on the multi- 
point link connection use the same XID 
type or phen null XID polling is used. 


REDUCING SYSTEM DEFINITION FOR NONSWITCHED 
LINK CONNECTIONS. 


Not all point-to-point nonswitched Link con- 


ACTIVATION 


Upon a request from NOF or SS to activate a 
link, CS completes the following steps: 


1. Creates DLC. 


2. Instructs OLC to activate the hardware 
port. 


3. Instructs DLC to send XID3s (using XID3 
I-fields provided by CS) to the adjacent 
link station, and receive back, from DLC; 
the XID3 I-fields returned by that adja- 
cent link station. 


4. If the local link station is primary, 
instructs DLC to send the mode-setting 
command. 


5. Receives notification from DLC that the 
contact phase has completed. 


6. Creates a path control instance. 


On completion of these steps, the link is 
considered active. 


DLC responsibilities during Link activation 
vary based on whether the link station is 
ABM, ABME, normal response mode (NRM), or NRM 
extended (NRME), and also upon whether the 
link station is primary, negotiable, or sec- 
ondary. Specifics on these variations are 
given in the following sections, but the gen- 


eral DLC responsibilities during link acti- 


vation are: 


® Function as the endpoint of the link con- 
nection. 


® Until the hardware port is activated, DLC 
ignores any received I-frames. 


nections are multipoint-capable. When at 
least one of the stations on these con- 
nections has a negotiable role, the system 
definition requirements at both ends may be 
reduced as follows: 


e The local link = station role may be 
defaulted to negotiable. 


® The secondary station address of the 
local link station may be given a default 
value. 


e There is no need to know the secondary 
link station address of the adjacent link 
station. If the value is needed, it will 
be acquired during XID negotiation. 


® When null XID polling is used with the 
broadcast address, there is no need to 
know the adjacent node type or the XID 
format type expected by the adjacent 
node. 


e When the hardware port is activated, 
assume the state of disconnected mode 
(DM). 


¢ Until notified by CS, respond to any 
received BLU with a DM response. 


e Receive and execute requests from CS for 
XID3 exchange and transmission of the 
mode-setting command. 


° Forward responses received on the link to 
cs. | 


RULES FOR OPERATION OF NRM LINK STATIONS 


An NRM/NRME link station may be configured as 
primary, negotiable, or secondary. The fol- 
lowing rules apply when DLC is activated by 
CS for both switched and nonswitched SDLC 
connections: 


Rules for primary DLC: 


® OLC never sends responses. 

¢ On links for othich the secondary station 
address is not assigned at system defi- 
nition, DLC uses the broadcast address 
until the station address is received 
from the secondary link station. | 

e When DLC sends a command, it starts a 
response inactivity timer that is reset 
by receipt of a valid response. (See 
Synchronous Data Link Control Concepts 
for details.) If the timer expires, the 
command 1S sent again. Commands are 
re-sent up to the retry limit. For poll- 
ing on nonswitched link connections, the 
retry limit may be infinite. 
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e DLC accepts, as a response to a command 
sent, any BLU it recetves that contains a 
unique secondary address or the broadcast 
address in the SDLC header. This accept- 
ance allows connections to be established 
between link stations that are both capa- 
ble of assuming the role of the primary 
link station (negotiable-negotiable, or 
primary-negotiable). Acceptance also 


allows one primary link station to. 


receive XIDs from another primary link 
station. CS can then recognize when two 
primary stations are trying to contact 
each other; this is an error situation. 

e BLUs received when no Poll bit is out- 
standing are discarded. 

® A primary DLC never sends a mode-setting 
command with the broadcast address, 
xX" FE™. 


Rules for negotiable DLC: 


® DLC sends commands and responses. 

® OLC uses the broadcast address, X'FF', in 
the DLC header of all commands sent until 
link station roles are determined. If 
the DLC becomes the primary link station, 
it continues to use the broadcast address 
until the station address is received 
from the secondary link station. 

° When DLC sends a command, it starts a 
response inactivity timer that 1s reset 
by receipt of a valid response. If the 
timer expires, the command is sent again. 
Commands are -_ re-sent up to an 
implementation-defined retry limit. For 
polling on nonsnitched link connections, 
the retry limit may be infinite. 

® DLC sends an XID response after receipt 
of an XID command. 

¢ DLC accepts any BLU it receives that con- 
tains the broadcast address in the SDLC 
header. 

® DLC puts its secondary station address in 
the DLC header of all responses it sends. 

e By direction of CS, DLC is able to assume 
the primary or secondary role. 


Rules for secondary DLC: 
e DLC never sends commands. 


¢ DLC sends an XID response upon receipt of 
an XID command. 


e DLC always puts its secondary station. 


address in the SDLC header. 


Link stations maintain state machines that 
enable them to distinguish XID commands from 
responses. A link station does not send a 
response to a command received from an adja- 
cent link station without allowing CS to 
process the XID. Link stations pass notifi- 
cation of the receipt of an XID command along 
with any I-field received to CS, which exam- 
ines it and the I-field received, changes any 
fields required by role determination proce- 


dures, and returns to DLC the XID to be used | 


in the response. 


In order to accommodate implementations not 
at the current level of SNA, negotiation pro- 
tocol receive-logic is tolerant of immediate 
responses from the adjacent link station, 


even though immediate responses are never 
sent. 


RULES FOR OPERATION OF ABM LINK STATIONS 


For information on ABM/ABME operation of link 
stations, see the IBM Token-Ring Network 
Architecture Reference. 


OPERATION ON HALF-DUPLEX POINT-TO-POINT CIR- 
CUITS 


XID Collision Avoidance 


Two link stations with negotiable or primary 
capabilities may simultaneously transmit 
their initial XID commands, causing a colli- 
sion on the link. To avoid this condition, 
negotiable Link stations delay the 
retransmission of the XID during the polling 
process by a random amount of time. This 
randomization continues until a response to a 
poll has been received. An implementation 
determines a finite range of timeout values. 
IBM implementations typically specify time- 
outs in the range of 2-20 seconds, but allow 
installation managers to specify their osm 


. timeouts. 


Modem Equalization 


Modem equalization is the transmission of 
training sequences between two modems after 
the link connection is established. For 
example, it is used by modems that meet CCITT 
recommendation V.27-ter when they are con- 
nected on snitched 2-wire circuits. Such an 
equalization procedure is initiated the first 
time a link station requests its (local) mod- 
em to transmit, and consists of a training 
sequence transmitted to the adjacent modem, 
allowing the adjacent modem to equalize. 
This equalization procedure is completed 
before the local modem gives the link station 
permission to proceed with the requested 
transmission. If an adjacent link station 
attempts to transmit while its modem is 
receiving the training sequence (i.e., while 
equalizing}, the modem will not be properly 
equalized. 


When a pair of link stations connected on a 
Switched 2-pire circuit have negotiable 
roles, or one has a negotiable role and the 
other has a primary role, both stations can 
request their modems for permission to trans- 
mit initial XIDs at almost the same time. To 
allow modem equalization to complete proper- 
ly» one of the link stations must delay the 
transmission of its initial XID for a time 
period longer than the sum of: the equaliza- 
tion procedure duration and the signal propa- 
gation delays. This time period is termed 


the equalization delay. 
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By convention, it is the called link station 
that delays the transmission of its initial 
XID for this equalization delay. This delay 
iS not required on 4-nhire circuits feven for 
switched link connections), nor is_ it 
required for all modem types. It is also not 
required for link connections on the IBN 
tcken-ring or public data netnorks such as 
X.25. Since the equalization delay depends 
upon the modem type, the circuit type, and 
the signal propagation delays, it must be 
specified as a system definition parameter; a 
value of 0 is allowed. 


The following conventions are used for modem 
equalization: 


e The called link station always delays its 
initial transmission for the specified 
equalization delay. 


° The calling link station is almays the 
first to transmit (if it is not defined 
as secondary). 


e A calling link station that is defined as 
secondary may behave in one of two ways. 
It may raise request-to-send, to perform 
its equalization procedure, as soon as 
the link connection is established, and 
then wait to transmit its initial XID 
until it receives an XID from the called 
link station. Or, it may delay its 
equalization procedure until after the 
called link station has performed its 
equalization procedure and = transmitted 
its initial XID. If the calling link 
station elects to delay, it will perform 
its equalization procedure and transmit 
its initial XID after it receives an XID 
from the called link station. 


A link connection may be established with a 
node that-does not follow the first conven- 
tion above; a called link station itn such a 
node does not delay transmission of its ini- 
tial XID for the specified equalization 
delay. In this case, the calling link sta- 
tien does not attempt to perform its equal- 
ization procedure after initial establishment 
of the link connection. Instead, modem 
equalization occurs during the normal trans- 
mission of the XID. Link connections to such 
nodes are identified by system definition 
procedures. 


Implementation of these conventions requires 
a link station to Know whether it is the 
calling or called = link station. When 
auto-call and auto-answer are used, this 
information may be deduced from the combina- 
tion of commands received from CS and the 
modem signals. When manual call and manual 
answer are used, this information may not be 
available to the Link station. An 
implementation-defined signal triggered by a 
user or operator may be required to allow the 
link station to function properly. 


3 


RULES FOR SEQUENCING XIDS 


The Exchange State indicators field in the 
I-field of each XID3 provides the basis for 
XID sequencing within four contexts: 


° Exchange State indicators not supported® 
° Prenegotiation 
° Negotiation proceeding 


e Nonactivation 


Nonactivation occurs after the contact phase 
has completed and is not a part of link acti- 
vation; it is discussed here for complete- 
ness, as the sequencing rules used apply for 
all four contexts. 


The following rules are in effect: 


° After a link station sends the initial 
XID, it sends another XID only in 
response to a received XID or 1f an XID 
has not been received within an 
implementation-specific timeout limit. 


¢ Activation XID exchanges terminate when 
link station roles of the link stations 
complement each other; i.e.» one is pri- 
mary and the other is secondary. 


In those cases in which both link stations 
initiate polling, the polling XIDs may be 
sent almost simultaneously. Consequently, 
the resulting XID exchance may have an asyn- 
chronous appearance until the link station 
roles have been resolved. 


RULES FOR XID EXCHANGE 


The following rules apply to XIDs exchanged 
during link activation: 


1. Null XIDs are sent as commands only for 
polling purposes 


2. T2.1 nodes send only XID3 as a response 
to an XID command 


3. All primary and negotiable link stations 
are able to accept a null XID as a 
response. Because the link stations may 
initiate the link activation XID 
exchanges independently, a command sent 
from one station may be interpreted by 
the other as a response. 


G4. All defined fields in the XID3 except 
those involved with negotiation protocols 
are not subject to change in XID3s that 
have the ESI set to "Negotiation Proceed- 
ing" or "Exchange State Indicators Not 
Supported." 


Implementations awaiting a prenegotiation XID recognize this migration condition, consider 


it as a prenegotiation XID3, and transmit a prenegotiation or negotiation-proceeding XID3. 
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5. The negotiation phase is complete shen 
each link station has sent and received 
at least one XID3 pith a complementary 
nNonnegotiable role and the ESI set to 
"Negotiation Proceeding" or "Exchange 
State Indicators Not Supported." 


Prenegotiation XID Exchange 


Flows representing prenegotiation exchanges 
are shown in Figure 2-1 on page 2-2. Within 
the optional prenegotiation XID exchange, 
there are two possibilities: the first is 
the flow beginning with a null XID; the sec- 
ond is the flow that skips the null XID and 
polls with a prenegotiation XID3. A compar- 
1son of these sequences shons that the prene- 
gotiation exchange can be completed more 
efficiently if an XID3 ts used for polling. 
Therefore, a prenegotiation XID3 is the pre- 
ferred manner of polling if it is Known that 
the adjacent node supports receipt of XID3s, 
1.@., is a T2.1 node. 


T2.1 nodes poll up to an 
implementation-specified retry Limit or until 
a response is received from the polled node. 
If the polled node is ready to enter into an 
XID exchange, it responds with a prenegoti- 
ation or negotiation-proceeding XID3. If the 
polled node is not ready to negotiate, it may 
either not respond at all or send a Discon- 
nected Mode response (DM). 


Negotiation XID Exchange 


As shown in Figure 2-1 on page 2-2, there are 


tuo ways to enter the negotiation-proceeding 
XID exchange: directly, or by means of an 
optional prenegotiation XID exchange. A T2.1 
node that has received a prenegotiation XID3 
response to an XID poll may send a 
negotiation-proceeding XID3. 


During this negotiation phase, the link sta- 


tion roles (primary and = secondary) are 
resolved cooperatively by the two link 
stations. Also, the ODAI value to be used at 


each node is determined as a result of the - 


link station role negotiation. The algo- 
rithms that are employed in determining the 
values of negotiated XID3 fields are dis- 
cussed below. The negotiation-proceeding 
phase not only completes the identification 
of the node and its adjacent node but also 
cooperatively determines one or more attri- 
butes:of the link betueen the tro nodes. The 
negotiation-proceeding XID exchange concludes 
when each negotiable field has been resolved 
and the contact phase completed. 


ABM stations are capable of sending a 
response while a command is still outstand- 
ing. During the link = activation XID3 
exchange, this may result in the receipt of a 
prenegotiation XID3 after a 
negotiation-proceeding XID3 has been sent. 
The appropriate response in this case is to 
retransmit the negotiation-proceeding XID3 
rather than treat the prenegotiation XID3 as 


a protocol error. For the same reason, an 
ABM station may receive an XID3 after a SABM 
or SABME has been sent. 


LINK STATION ROLE NEGOTIATION: During the 
link activation XID exchange, before link 
station roles have been determined, the ini- 
tial link station roles may be primary, sec- 
ondary,» or negotiable. The role of the link 
station jis specified in the XID3 (see "Link 
Station Role of the XID Sender" on page 2-12 
for details) and, together with the adjacent 
node's link station role, determines whether 
a link station will negotiate its role. Fig- 
ure 2-3 shows the extent to which a link sta- 
tion will negotiate for all combinations of 
link station roles. Only when both stations 
are negotiable is there any negotiation mith 
respect to link station roles. 


When the link station role flags indicate 
that role negotiation is required, the Node 
Identification fields (composed of Block Num- 
ber and ID Number fields; see "Node Identifi- 
cation Field" on page 2-12 for details) in 
the received and sent XID3s are compared. CS 
assigns its link station the DLC primary role 
if its Node Identification field is the 
greater of the to, and the DLC secondary 
role if its Node Identification field is the 
lesser. 


If the Node Identification field in a 


‘received XID3 is equal to that of the receiv- 


ing node's XID3, the receiving CS randomizes 
its Node Identification ID Number field pith 
a value in the range X'OOOQ00'-X'FFFFF'. At 
the same time, it sets the Block Number field 
to either X'000' or X'FFF', indicating that 
the Node Identification field does not pro- 
vide a unique node identification. An XID3 
containing the randomized Node Identification 
field is then transmitted and, on receipt of 
the XID response from the adjacent link sta- 
tion, the comparison of Node Identification 
fields is performed again. | 


A new random node identification ID number 
will be generated at most twice. If the con- 
dition of equality persists after the second 
randomization, CS will terminate the XID 
exchange (see “Control Vectors" on page 2-14 
for a discussion of control vector X'22'). 


If as a result of randomizing the ID number 
the role determination negotiation can be 
completed, ji.e., one node's field has a 
greater value than the other's, the original 
values of the Node Identification field in 
each node's XID3 are restored, after the link 
station roles have been negotiated. 


ROLE CONSIDERATIONS FOR ABM LINK STATION: 
For ABM stations, primary and secondary link 
station roles have no relevance beyond deter- 
mining hich station will send the 
mode-setting command and how the ODAI bit 
will be set. 


ODAI VALUE DETERMINATION: T2.1 nodes must 
agree on the ODAI that will be used when 
activating sessions, 1.@.» when sending BIND. 
The node with the primary link staticn sets 
its ODAI value to 0, while the node with the 
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LINK STATION ROLE FLAG RECEIVED 


System definition 

error Primary Primary 
System definition 

Secondar Secondary error Secondary 


Figure 2-3. Outcome of Link Station Role Comparison: The table entries show the outcome for the 
sending link station. Only in the case that both stations are negotiable is any 
additional role negotiation necessary. 


LINK Primary 


STATION 


ROLE 


FLAG 


SENT 


secondary sets its ODAI value to 1. Thus, tiated. Rather, it is a by-product of the 
the ODAI value is not actually directly nego- link station role negotiation. 


NONACTIVATION XID EXCHANGE 


After completion of the contact phase, or of control vector X'0E', type X'F4', may change 
a prior nonactivation exchange, information in a nonactivation exchange. 

at one node associated with a link = may 

change. An XID3 exchange, currently initi- Rules for sequencing nonactivation XID 
ated only by the primary link station, is exchange are given in "Rules for Sequencing 
used to communicate these changes. The XID3s XIDs" on page 2-7. 

sent in these exchanges have their ESI set to 

“Nonactivation,' and the scope of negotiable Figure 2-4 on page 2-10 shows the flows that 
fields that may change is more limited than occur when a primary Link station initiates a 
in the case of activation exchanges. Cur- nonactivation XID3 exchange. 


rently, only the contents of the Network Name 
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Figure 2-4. 


10 


Node A Node B 
Completion of Contact Phase ; 
; XID3 (ESI = nonactivattion) : 
] Cyrene tnt tment > CY 
: XID3 (ESI = nonactivation) ‘ 
é RR, RNR, or I-Frame ‘ 
3 6 EEE 


Nonactivation XID3 Exchange, Primary Initiated 


The following notes are keyed to Figure 2-4. 


1. 


Because of local changes,» node A needs to 
initiate a nonactivation XID exchange. 
It does so by sending a nonactivation 
XID3. Since it contains the primary Link 
station, it may send a nonactivation XID3 
at any time after the contact phase has 
completed. The nonactivation XID3 will 
contain any information about node A that 


has changed at its node since the last 


XID exchange. 


Node B responds with a nonactivation 
XID3. It may also convey information 
changed since the last XID3 exchange. 


Node A sends an RR, RNR» or I-frame with 
the Poll bit set to 1, signalling node B 
that the exchange is completed. 
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GENERAL RULES FOR ALL DLCS 


°® The primary initiates a nonactivation 
exchange by means of an XID3 with the ESI 
set to "Nonactivation." 


® The primary does not tnitiate a nonacti- 
vation exchange when the adjacent node is 
sending RNR. 


e When the primary link station sends a 
nonactivation XID3, the Poll bit is set 
to l. 


e When the secondary link station sends a 
nonactivation XID3, the Final bit is set 
to l. 


RULES FOR OPERATION OF NRM LINK STATIONS 


NRM link stations handle signals from the 
adjacent node during a nonactivation exchange 
using the following rules: 


e When the primary is sending a nonacti- 
vation XID3, any I-frames it has to send 
are sent before the nonactivation XID3. 
In this case, the I-frames do not have 
their Poll bit set to 1 and the XID3 
does. 


® When a= secondary link station that is 
engaged in a  nonactivation exchange 
receives RR, RNR, or an I-frame with the 
Poll bit set to 1, 1t informs CS. This 
Signals the completion of the nonacti- 
vation exchange for the secondary link 
station. | 


DEACTIVATION 


The steps followed by CS when deactivating a 
link are as follows: 


1. CS notifies DLC that the link should be 
deactivated. : 


2. CS receives notification that the link is 
7n disconnect mode. 


3. CS notifies DLC that the local link sta- 
tion should be destroyed. 


4. CS destroys the path control instance 
associated mith the link. 


DLC, when told to deactivate the link by CS, 
performs the DLC command sequences appropri- 
ate to its role as primary or secondary link 
Station. (See appropriate DLC document for 
details.) The primary link station sends 


e XID3 is the only response that the sec- 
ondary link station can send to an XID3 
command from the primary link station if 
the link 1s to continue. The other sec- 
ondary link station responses to XID3 
(RD, DM, RIM, and FRMR) are treated by 
the primary link station as errors. 


e When an error is detected in the course 
of a nonactivation exchange, the primary 
sends Disconnect to initiate the process 
of deactivating the link. 


e When CS enters into ao nonactivation 
exchange, the DLC layer is informed. 


e When the secondary link station 1s 
responding to a nonactivation XID com- 
mand, I-frames are not allowed to precede 
1ts XID3 response. 


RULES FOR OPERATION OF ABM LINK STATIONS 


ABM link stations handle signals from the 
adjacent node during a nonactivation exchange 
using the following rules: 


° After sending a nonactivation XID3 com- 
mand, the primary can receive” and 
acknowledge RNR, RR, or any I-frame com- 
mand with the Poll bit set to 1. 


e When an error is detected in the course 
of a nonactivation exchange, either node 
may send Disconnect to initiate the proc- 
ess of disconnecting the link connection. 


Discormect and receives back UA from the sec- 
ondary link station. The secondary link sta- 
tion sends Request Disconnect, receives 
Disconnect from the primary link station, and 
responds with UA. After either station 
enters disconnect mode the link comection 
may be terminated by CS tn either node. 


If the secondary receives the deactivation 
command from CS and has other responses pend- 
ing (such as acknowledgments for received 
information frames or responses to received 
unnumbered commands), the RDB is not sent 
Immediately. When the Disconnect command 
from the primary link station 1s not received 
because the primary chooses to ignore the RD 
response, the RD response 1s repeated at the 
next response opportunity; incoming frames 
other than the expected Disconnect are 
accepted and responded to. 
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Figure 2-5. 


A T2.1 node sends only a null XID or an XID3; 
both are enclosed in a basic link unit (BLU) 
and each, therefore, consists of a link head- 
er, an I-field (in the case of XID3), and a 
link trailer. The LH indicates that the BLU 
is an XID. This section highlights those 
fields and control vectors of the XID that 
are important to the T2.1 node, as well as 
the error conditions associated with the use 
of XID3. 


T2.1 nodes ignore unrecognized fields and 
control vectors received in xXID3s, 1.e., 
reserved bits are not checked and unknooum 
control vectors do not cause error condi- 
tions. XID3 senders do not echo received 
unrecognized fields and control vectors. 


MAJOR XID3 FIELDS USED BY T2.1 NODES 


The following section discusses the major 
fields of the XID as used by T2.1 nodes; ''Ap- 
pendix B. XID, RUs, Control Vectors, and 
Sense Data" provides a detatrled 
field-by-field description of XID Format 3 
(XID3). 


Node Identification Field 


This field ts composed of two parts, the 
Block Number and ID Number fields. When the 


ABM Capable 


Negotiation 
continues 


WA Or xX 


ABM Capable 


Error condition 


Not ABM Capable 


CV X'22' 
next XID3 


37-0 < =~ 90 0 BD 


MAREE EA CE i GEA NEES 


The settings of the Link Station Role of the 
XID Sender field (byte 19, bits 2-3) have the 


XID3 Sender 


SABM or SABME sent as 
mode-setting command 


sent on 


Node Identification field is not to be taken 
as a unique node identifier, the Block Number 
field (bits 0-11 of bytes 2-5) is set to 
either X'000' or X'FFF'. See "Link Station 
Role Negotiation" on page 2-8 for a dis- 
cussion of how this may occur. Otherwise, 
implementation information is used as indi- 
cated in individual implementation speci fica- 
tions. 


ABM Support Indicator 


The settings of the ABM Support indicator 
(bit 1 of byte 19) have the following 
meanings : | 


® XID sender cannot be a combined ABM sta- 
tion. 


e XID sender can be a combined ABM station. 


It is an error condition if one station is 
ABM capable and the other 1s not. If both 
stations are ABM capable, link activation 1s 
concluded with SABM or SABME as_ the 
mode-setting command; if both stations are 
not ABM capable, the mode-setting command 
will be SNRM or SNRME. Figure 2-5 summarizes 
outcomes for the possible sent and received 
values of the ABM Support indicator. 


Not ABM Capable 


Error condition 


CV X'22' 
next XID3 


sent on 


Negotiation 
continues 


SNRM or SNRME js sent as 
mode-setting command 


Resolution of ABM Capabilities in XID3 Senders and Receivers 


following meanings: 


XID sender is a secondary (nonnegotiable) 
link station. 
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Figure 2-6. 


e XID sender is a primary (nonnegotiable) 
link station. 


° XID sender is a negotiable link station 
with the capability of being either a 
primary or secondary link station. 


See "Link Station Role Negotiation’ on page 
2-8 for the details of this role negotiation. 


I-Frames Received before Acknowledament 


Bits 1-7 of byte 27 of XID3 contain the spec- 
ification of the maximum number of I-frames 
that a link station may receive before it 
sends an acknowledgment. This field implies 
the modulus for the send and receive sequence 
counts. If this field has a value that is 


Implied 
Sequence Number 
Modulus 


SNRM 


Station 1 Maximum I-Frames 
before Acknowledgment 


= as sent 


Station 2 Maximum 
I-Frames before 


Acknowledgment = 


SNRM 


Station 1 Maximum J-Frames 
before Acknowledgment 


Station 2 Maximum 
I-Frames before 
Acknowledgment = 


as sent 


as sent 


less than 8, the sequence number modulus is 
8; otherwise, it is 128. 


SDLC CONSIDERATIONS FOR MODULUS RESOLUTION: 
All SDLC link stations have the capability of 
using 8 as their modulus. Optionally, a link 
station may have the capability of using 128. 
Any link station that can use 128 as its SDLC 
modulus announces this capability in the 
activation XID exchange. Such a link station 
must be prepared to use a modulus of 8 ona 
link if the adjacent link station declares a 
modulus of 8. In such a case, the 
mode-setting command ts SNRM instead of 
SNRME. If the secondary link station does 
not receive the appropriate command, it 
responds with DM. Figure 2-6 summarizes the 
manner in which differences in the modulus 
numbers for sequence numbers are handled for 
SDLC and X.25 link stations. 


Station 2 


SNRM 


Station 1 Maximum J-Frames 
before Acknowledgment 
= as sent 


Station 2 Maximun 
I-Frames before 
Acknowledgment 


SNRME 


Station 1 Maximum I-Frames 
before Acknowledgment 
= as sent 


Station 2 Maximum 
I-Frames before 
Acknowledgment = as sent 


Resolution of Modulus Differences in Maximum Number of I-frames Received before 


Acknowledgment: For SDLC links, the value sent by either link station does not change 
in the course of the XID activation exchange. Recognition of differences in the sent 
and received values 1s expressed only in the mode-setting command. 


Since the value that an SDLC link station 
sends in this field does not change in the 
course of the XID exchanges, a link station 
that alters its capability of using 128 to 8 
does not have a chance to declare the maximum 
number of I-frames that it can receive before 
acknowledgment. In such cases, it adopts 7 
as the maximum number of I-frames received 
before acknowledgment. And, for its part, 
the link station that originally declared 
itself to use a modulus of 8 assumes that the 
adjacent link station's maximum number of 
I-frames received before acknowledgment is 7. 


IBM TOKEN-RING CONSIDERATIONS FOR MODULUS 
RESOLUTION: IBM token-ring link stations 
support only ABME protocols, 1.e., they use 
128 as a modulus for sequence number counts. 
Therefore, the maximum number of I-frames a 
station may receive before acknowledgment 
does not imply a sequence count. It is pos- 
sible, for example, that a token-ring link 
station may send 6 in this field but still 
will accept or send SABME. Any link station 
intending to connect to a token-ring Link 
Station always uses 128 as a modulus and 
accepts or receives SABME as a_ mode 
setting-command. A token-ring Link station 
will respond to SABM with DM. 
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X.25 CONSIDERATIONS FOR MODULUS RESOLUTION: 
X.25 link stations support two types of data 
link control: qualified logical link control 


(QLLC) and enhanced logical link control 


(ELLC). ABM corresponds to QLLC, ABME to 
ELLC, and the choice of ABM or ABME is 
dependent on system definition. There is no 
negotiation of modulus values. 


PARAMETER ERRORS: A parameter error occurs 
if one of the link stations declares that 0 
is the maximum number of I-frames that it may 
receive before acknowledgment. In this case, 
XI03 negotiation is terminated with control 
vector X'22' on the next XID3 sent. 


CONTROL VECTORS 


CS appends control vectors at the end of the 
XID3 and, minimally, the following control 
vectors are required by sending nodes at the 
current level of SNA. The absence of these 
control vectors does not, however, constitute 
an error condition for ae receiving node. 
This allows T2.1 nodes not at the current 
level of SNA to attach to current-level 
nodes. 


® Network Name control vector X'O0E', type 
X'F4'—CP Name 


The Network Name control vector X'0E’, 
type X'FG', contains the 17-byte 
network-qualified CP name (see "Control 
Vectors" in Appendix B for details). As 
a sender, 1 to 7 bytes of the network 
identifier is used, although a receiving 
T2.1 node must accept up to 8 bytes. 


The presence of this control vector ina 
received XID3 is an indicator that the 
ESI field is supported. See "Rules for 
Sequencing XIDs'" on page 2-7 for a dis-~- 
cussion of the ESI field. 


® Network Name control vector X'0E', type 
X'F7'—Adjacent Link Station Name 


All XID3s include this control vector. 
® Product Set ID control vector X'10' 


All XID3s include a Product Set ID con- 
trol vector of 60 bytes or less in 
length. 


A fourth control vector is used by T2.1 nodes 
for reporting error conditions: 


e XID Negotiation Error control vector 
X'22' 


This control vector is appended to the 
XID3 when an error has been detected, and 
contains a pointer to the first byte and 
first bit of the field in the received 
XID3 that was In error. The received 
(erroneous) XID3 is discarded. The pres- 
ence of control vector X'22' on the 
received XID3 is a signal that the XID 
exchange will be terminated. 


XID3 EXCHANGE ERRORS 


The errors described below are reported to 
the adjacent node with control vector X'22' 
appended to the detecting node's XID, except 
as noted for the invalid station address 
error. If more than one error is detected, 
multiple instances of control vector X'22' 
may be appended as long as the XID3 I-field 
does not exceed the length restriction of 255 
bytes. Control vector X'22' initiates termi- 
nation of the XID exchange and, whether sent 
by the primary or secondary, eventually leads 
to Disconnect being sent by the primary Link 
station. If a node subsequently attempts to 
reactivate the link is 
implementation-dependent. See "Control Vec- 
tors" for further discussion of control vec- 
tor X'22°. 


XID3 exchange error conditions: 


¢ The XID3 is limited in length to 255 
bytes. If an XID3 is received that is 
longer than this limit, the error can be 
reported in control vector X'22' with a 
pointer to bit 0 of byte 256. This check 
1s not required if the DLC will detect 
the error. 


e There is a disagreement between the num- 
ber of bytes in the XID I-field and the 
length given in byte 1 of the XID3 
I-field. | 


® Control vector X'OE', type X'F4', is 
appended to the XID3, but the ESI field 
is set to exchange state indicators not 
supported. 


° Validation of the CP name tn control vec- 
tor X'OE', when present, is performed. 


°® Validation of the Node Identification 
field is performed. See "Node Identifi- 
cation Field” on page 2-12. 


°e Validation of the DLC type field is per- 
formed. 


® Validation of the FID type field is per- 
formed. 


e If XID negotiation has been completed and 
the station address of the adjacent link 
station is X'FF', it is an error condi- 
tion and the link is declared inopera- 
tive. 


© Incompatibilities in link station roles 
may occur. See "Link Station Role of the 
XID Sender" on page 2-12. 


® Validation of station type (ABM capable 
or not) is performed. See "ABM Support 
Indicator" on page 2-12. 


@ Validation of the SDLC command/response 
profile is performed. 


® Validation of the Maximum BTU Length 
field is performed. See "Base Maximum 
BTU Sizes" in Chapter 4. 
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® Validation of the Maximum Number of 
I-Frames before Acknowledgment field is 
performed. See "I-Frames Received before 
Acknowledgment" on page 2-13. 


° Product implementations may choose to 
treat certain format errors (e.g., a 
non-XID3 I-frame received) as DLC errors; 
after an implementation-defined retry 
limit is reached, such errors will cause 
the link to be disconnected. 


°® The XID negotiation process may begin and 
not complete properly if one of the two 
link stations fails to change its role to 
a nomegotiable value. Therefore, once a 


XID3 FINITE-STATE MACHINES 


The CS finite-state machines (FSMs) are 
divided into two groups: activation and non- 
activation. The sections following discuss 
each separately. See "Appendix A. FSM Nota- 
tion" in Appendix A for a discussion of FSM 
notation. 


ACTIVATION XID3 FINITE-STATE MACHINES 


The four FSMs that follow for XID negotiation 
flows are connected together in the following 
way: FSM_XID3_T2PI_NODE on page 2-17 is a 
front-end FSM for the other FSMs» and 
FSM_XID3_NEG_PROTOCOL on page 2-21, 
FSM_XID3_PRI_PROTOCOL on page 2-25, = and 
FSM_XID3_SEC_PROTOCOL on page 2-27 perform 
the negotiation. The front-end FSM has a 
protocol boundary with the DLC manager and 
the routing and checking logic in CS. 


One negotiation FSM exists for each type of 
station (negotiable, primary, and secondary). 


link station sends a nonnegotiable XID3, 
1t counts the number of received XID3s 
with negotiable role set. When an 
implementation-dependent error count is 
reached, control vector X'22' is sent to 
the adjacent node. 


® In response to a polling null XID or an 
XID3, T2.1l nodes expect to receive an 
XID3. If an XID other’ than XID3 is 
returned, an XID3 1s sent in response. 
If the ALS persists in returning an XID 
other than XID3 beyond an 
implementation-defined retry limit, XID3 
with control vector X'22' pointing to the 
Format Identifier field is returned. 


These FSMs also have a protocol boundary with 
the DLC manager, but the information flous 
only to the DLC manager. All information 
from the DLC manager is input to the 
front-end FSM. 


Some general assumptions about the operation 
of the FSMs are: 


® For all links, anything received before 
link activation is discarded. 


e For nonswitched Link connections, an XID 
or mode setting command received after 
the hardware port has been activated, and 
before the contact phase has begun, 15 
answered with DM. 


e When an error is detected in any of these 
FSMs, the disconnect procedure is auto- 
matically executed. 


® The SEND_RECEIVE_DIRECTION is initialized 
to SEND for these FSMs. 


Chapter 2. Configuration Services 2-15 


FSM_XID3_T2P1_NODE 
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FSM_XID3_T2P1_NODE 


FUNCTION: 


INPUT: 


OUTPUT: 


FSM_XID3_T2P1_NODE 


This FSM governs that portion of the XID exchange that is not dependent on 
link station role and provides input to the FSMs that are specific to link 


station role. 


The following are the input to this FSM: 


ALS_CONNECTED_IN 


ALS_CONNECTED_OUT 


CONTACT_ALS 


RECVD_XID 


NULL_XID 


ALS_CONTACTED 


RCV_SET_MODE 


ALS_DISCONTACTED 


RESET 


VARIOUS CONDITIONS 


A signal from the DLC manager that indicates that an 
Incoming call has been received. 


A signal from the DLC manager that indicates that a 
connect-out procedure has been successfully completed. 


A signal from configuration services that initiates the 
contact phase. 


A signal from the DLC manager containing the XID3 I-field. 


A signal from the DLC manager indicating that a null XID 
has been received. 


A signal from the DLC manager that indicates that a 
mode-setting sequence has occurred. 


A signal from the DLC manager that indicates that a 
mode-setting command has been received. 


A signal from the DLC manager that indicates that 
link-level contact with an adjacent link station (ALS) has 
been terminated and that the connection to the ALS has 
been deactivated. 


A signal indicating that the connection should be consid- 
ered to be inactive by this finite-state machine. 


The results of successful Boolean tests on specific XID3 
fields. For example, the input ESI_NOT_SUPFORTED indi- 
cates that the adjacent link station sets its exchange 
state indicators to "Exchange State Indicators Not Sup- 
ported." . 


The following are the output from this FSM: 


RECVD_XID 


SEND_XID 


A signal containing the XID3 I-field received by the DLC 
manager. This signal is either passed to configuration 
services routing and checking logic or to one of the FSMs 
that are specific to link station role; or to both. 


A signal containing the XID3 I-field to be sent to the 
adjacent link station (ALS). This signal is passed either 
to the DLC manager or to one of the FSMs that are specific 
to link station role. XID3 exchange is currently being 
conducted. 


SEND_RECEIVE_DIRECTION An internal signal indicating whether the XID3 being 


NULL_XID 


-passed to the FSM that 1s link station role specific 15 an 


XID3 to be sent (5), an XID3 that has been received (R), 
or an XID3 used to initialize (I) but that will not be 
sent. 


The null XID sent to a T2.1 node. 
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FSM_XID3_T2P1_NODE 


Referenced procedures, FSMs, and data structures: | 
FSM_XID3_NE6_ PROTOCOL page 2-21 


FSM_XID3_PRI_PROTOCOL page 2-25 
FSM_XID3_SEC_PROTOCOL page 2-27 
SEND_RECEIVE_DIRECTION page 2-36 
COMMAND _ RESPONSE _RCV_INDICATOR page 2-36 
SEND _XID page 2-36 
RECVD_XID page 2-37 


STATE NAMES---->{ START / WAIT | RCVD|WTNG 


STATE NUMBERS-->/01 
ALS_CONNECTED_IN 


ALS_CONNECTED_OUT 
CONTACT_ALS N 


RECVD_XID, ts 
ESI_NOT_SUPPORTED 6B 
RECVD_XID, 

PRE_NEGOTIATION_EXCHANGE 4LI4M 
RECVD_XID, 

NEGOTIATION_PROCEEDING , ot i K 
NULL_XID -c 


RCV_SET_MODE a K D . K yg K i i. As ae oT tee 2 eed 
ALS_CONTACTED 10 GI10 GI/ 
ALS_DISCONTACTED = ae! as a hee ey ee ye ee] re rsh 
meat an Nee 2 


OUTPUT FUNCTION 
CODE 


onn 
x= > > 
> | 
a 
WN 


NN NN OON ‘“ 


(Received ALS_CONNECTED_* as the first input during the connect 
phase. The link-station-role-specific FSM that will be used 
throughout the XID exchange is set). 


Set XID Exchange State field in XID3 to "Prenegotiation Exchange." 
Select based on Link-Station Role of XID Sender field tn SEND_XID: 
When set to "Negotiable" 
Set #FSM_XID3_PROTOCOL to FSM_XID3_NEG PROTOCOL. 
Send NULL_XID to the OLC manager. 
Set COMMAND_RESPONSE_RCV_INDICATOR to RESPONSE. 
When set to "Sender is a Primary Link Station" 
Set #FSM_XID3_PROTOCOL to FSM_XID3_PRI_PROTOCOL. 
Send NULL_XID to THE DLC manager. 
Set COMMAND_RESPONSE_RCV_INDICATOR to RESPONSE. 
When set to "Sender is a Secondary Link Station" 
Set #FSM_XID3_PROTOCOL to FSM_XID3_SEC_PROTOCOL. 
Set COMMAND_RESPONSE_RCV_INDICATOR to COMMAND. 


B (Received an XID3 and the adjacent node set its exchange state indicators 
to "Exchange State Indicators Not Supported." Verify node ID before 
calling &8FSM_XID3_PROTOCOL to avoid ng the ID number affected by 
randomization. ) 


Send RECVD_XID to configuration sacvicse pauting and checking logic. 
As a result, CONTACT_ALS will be an input to this FSM. 

Set SEND_RECEIVE DIRECTION to I (Initialize). 

Call #FSM_ XID3_PROTOCOL. 7 
Perform output code F. 
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(Answer an XID3 or null XID received with an XID3; one or more retry 
limits need to be applied here. This action code is used when not 
engaged in role determination. COMMAND _RESPONSE_RCV_INDICATOR does 
not change. ) 


Send SEND_XID to the DLC manager. 
(Received RCV_SET_MODE during connect phase. ) 


Send RECVD_XID I-field to configuration services 
routing and checking logic. As a result, CONTACT_ALS 
will be an input to this FSM. 

Call #FSM_XID3_PROTOCOL. 

If state of #FSM_XID3_PROTOCOL is PROTO_ERROR then 

Log error. 


(Received CONTACT_ALS after the connect phase or following 
RCV_SET_MODE. ) 


Set XID Exchange State field in SEND_XID to "Negotiation Proceeding." 
Set SEND_RECEIVE_DIRECTION to S (Send). 
Call #FSM_XID3_PROTCCOL. 


(Format and protocol check RECVD_XID; then send 
the correct response to RECVD_XID.) 


If state of #FSM_XID3_PROTOCOL is PROTO_ERROR or XID3_ERROR 
or 1f state of FSM_XID3_T2P1_NODE is PROTO_ERROR then 
Send SEND_XID to the DLC manager. 


Else 
Save RECVD_XID. 
Format check and validate the contents of RECVD_XID. 
If an error exists in the format or field contents then 
Append an XID Negotiation Error (X'22') control vector to SEND_XID. 
Set SEND_RECEIVE_DIRECTION to S (Send). 
Else 
Set SEND_RECEIVE DIRECTION to R (Receive). 
Call #FSM_XID3_PROTOCOL. 
If state of #FSM_XID3_PROTOCOL is PROTO_ERROR or XID3_ERROR then 
Log error. 


(Link station has completed a mode-setting sequence. ). 
Call 8FSM_XID3_PROTOCOL. 


(Received CONTACT_ALS as the first input during the contact phase. 
The link-station-role-specific FSM that will be used throughout 
the XID exchange is set). 


Select based on Link-Station Role of XID Sender field in SEND_XID: 
when set to "Negotiable" 
Set #FSM_XID3_PROTOCOL to FSM_XID3_NEG_PROTOCOL. 
When set to "Sender is a Primary Link Station" 
Set #FSM_XID3_PROTOCOL to FSM_XID3_PRI_PROTOCOL. 
When set to ''Sender 1s a Secondary Link Station” 
Set #FSM_XID3_PROTCCOL to FSM_XID3_SEC_PROTOCOL. 
Set XID Exchange State field in SEND_XID to "Negotiation Proceeding." 
Set SEND_RECEIVE DIRECTION to S (Send). 
Call #FSM_XID3_PROTOCOL. 


(Respond to null XID or RCV_SET_MODE in contact phase. ) 


Set SEND_RECEIVE_DIRECTION to R (Receive). 

Call #FSM_XID3_PROTOCOL. 

If state of #FSM_XID3_PROTOCOL is PROTO_ERROR then 
Log error. 


Chapter 2. Configuration Services 


FSM_XID3_T2P1_NODE 


(The adjacent link station has been discontacted. 
Reset the FSMs involved in XID3 processing. ) 


| Reset #FSM_XID3 PROTOCOL. 
Reset FSM_XID3_T2P1_NODE. 


(Received an XID before CONTACT_ALS and one of the following 
conditions exists: the received XID3 contained the wrong Exchange 
State field setting, a null XID was received after an XID3, an XID3 
was received after RCV_SET_MODE, or an inappropriate mode-setting 
command was received. ) 


Log error. 
Append an XID Negotiation Error (X'22') control vector to SEND_XID. 
Send SEND_XID to the DLC manager. 


(The first input from the adjacent link station was an XID3. 
COMMAND_RESPONSE_RCV_INDICATOR does not change value. ) 


Send SEND_XID to the DLC manager. 
Send RECVD_XID to configuration services routing and checking logic. 
As a result, CONTACT_ALS will be an input to this FSM. 


(The first input from the adjacent link station was a null XID.) 


Send RECVD_XID to configuration services routing and checking logic. 
As a result, CONTACT_ALS will be an input to this FSM. 
Select based on COMMAND RESPONSE_RCV_INDICATOR: 
When set to COMMAND 
Send SEND_XID to the DLC manager. 
When set to RESPONSE 
Set COMMAND_RESPONSE_RCV_INDICATOR to COMMAND. 


(Received CONTACT_ALS during the connect phase. ) | 
Set XID Exchange State field in XID3 to "Negotiation Proceeding." 
Select based on COMMAND RESPONSE _RCV_INDICATOR: 
When set to COMMAND 
| Set SEND_RECEIVE_DIRECTION to S (Send). 
Call 8FSM_XID3_PROTOCOL. 
Set CONMAND_RESPONSE_RCV_INDICATOR to RESPONSE. 
When set to RESPONSE 


Set SEND_RECEIVE_DIRECTION to I (Initialize). 
Call #FSM_XID3_PROTOCOL. 


(An XID3 is recetved. If COMMAND_RESPONSE_RCV_INDICATOR is 
set to COMMAND, a response to the received XID3 is sent to the 
DLC manager. If CONMAND_RESPONSE_RCV_INDICATOR is set to 
RESPONSE, no response is made, since the XID3 received is the 
response to the last XID3 in the prenegotiation exchange. ) 


Select based on COMMAND_RESPONSE_ RCV_ INDICATOR: 
When set to COMMAND 
Send SEND_XID to the DLC manager. 
When set to RESPONSE 
Set COMMAND _RESPONSE_RCV_INDICATOR to COMMAND. 


(An XID3 is received during prenegotiation exchange. Polling 
continues until the adjacent link station begins the negotiation- 
proceeding phase; a retry limit needs to be applied here. ) | 


Send SEND_XID to the DLC manager. 


(Received an XID after CONTACT_ALS and one of the 
following conditions exists: RECVD_XID contained 

the wrong Exchange State field setting, or a null XID 
was received after an XID3.) 


Log error. 
Append an XID egecietiea Error (X'22') control vector to SEND_XID. 
Send SEND_XID to the DLC manager. 
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FSM_XID3_NEG_PROTOCOL 


FUNCTION: This FSM describes the protocol for negotiable stations and maintains the 
state for a T2.1 node regarding the exchange of XID3s for the negotiable sta- 
tion. Additionally, this FSM sends a signal to the DLC manager’ that corre- 
sponds to the input received. When a protocol violation is detected, an XID 
Negotiation Error control vector is appended to SEND_XID. 


INPUT: The following parameters are the input to this FSM: 


SEND_RECEIVE_DIRECTION Indicates whether the XID3 being protocol checked by 
this FSM 1s an XID3 to be sent (S)> an XID3 that has 
been received (R), or an XID3 used to initialize this 
FSM to the correct state (I) but that will not be 
sent. 


ROLE_NEGOTIATION_FLAGS When SEND_RECEIVE_DIRECTION 1s equal to receive (R), 
the Link-Station Role of XID Sender field in- 
RECVD_XID 1s examined. This variable takes on the 
value found in that field, 1.e., NEGOTIABLE, PRIMA- 
RY_NONNEGOTIABLE, or SECONDARY _NONNEGOTIABLE. 


CR_INDICATOR An indicator that the DLC is using a_ frame format 
that contains an explicit command/response indicator, 
e.g.» for an ABM DLC. 


SEND_XID A signal to the DLC manager containing the XID3 
I-field to be sent to the adjacent link station. 


NULL_XID A signal that a null XID has been received or that 
one will be sent, depending upon the value of 
SEND_RECEIVE_DIRECTION. 


RCV_SET_MODE A signal from FSM_XID3_T2P1_NODE that a mode-setting 
command has been received. 

ALS_CONTACTED A signal from FSM_XID3_T2P1_NODE that a mode-setting 
exchange with an ALS has completed. 

RESET A signal indicating that the connection should be 
considered to be inactive by this” finite-state 
machine. 

VARIOUS CONDITIONS The results of successful Boolean tests on specific 


fields of SEND_XID and/or RECVD_XID. For example, if 
the Node Identification fields of SEND_XID- and 
RECVD_XID are equal, then NODE_IDS_EQ will be an 
input to this FSM. 


OUTPUT : The following parameters are the output from this FSM: 


SEND_XID A signal containing the XID3 I-field to be sent to 
the adjacent node. During role negotiation, 1t may 
be altered in the following manner: when the lecal 
node is negotiable, the Link-Station Role of XID 
Sender field of SEND_XID is altered to assume the 
negotiated role of "Sender is a Primary Link Station" 
or "Sender is a Secondary Link Station"; during nego- 
tiation, the Node Identification field is altered if 
XID3 sender and receiver have the same node identifi- 
cation field and both nodes are negotiable; itn the 
event of an error, an XID Negotiation Error control 
vector is appended. 


CONTACT_ALS_PRI/SEC A signal prompting the DLC manager to send (PRI) or 
answer (SEC) a mode-setting command. 


NULL_XID A signal instructing the DLC manager to send a null 
XID to the adjacent node. 
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Referenced procedures, FSMs, and data structures: | 
SEND_RECEIVE_DIRECTION page 2-36 
SEND_XID | page 2-36 


RES 


STATE NANMES----> 


STATE NUMBERS-->/01 


R, NEGOTIABLE, NODE_IDS_EQ 
R, NEGOTIABLE, CR_INUICATOR, 
RCVD_NODE_ID_EQ_OLD_NODE_ID 
R, NEGOTIABLE, 
SEND_NODE_ID_GT_RCVD_NODE_ID 
R, NEGOTIABLE, CR_INDICATOR, 


SEND_NODE_ID_GT_RCVD_NODE_ID 
R, NEGOTIABLE, 
SEND_NODE_ID_LT_RCVD_NODE_ID 
R, NEGOTIABLE, CR_INDICATOR, 

SEND_NODE_ID_LT_RCVD_NODE_ID 
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Ry PRIMARY_NONNEGOTIABLE 

Ry FRIMARY_NONNEGOTIABLE, 
CR_INDICATOR 

R, SECONDARY_NONNEGOTIABLE 
R, SECONDARY_NONNEGOTIABLE,» 
CR_INDICATOR 

R, NULL_XID 


R, XID3_WITH_CV22 . 
S» XID3_WITH_CV22 


S» XID3 
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S, NULL_XID 


Is NEGOTIABLE 


[RCV_SET_MODE 
RCV_SET_MODE, CR_INDICATOR 
ALS_CONTACTED 
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RESET 


OUTPUT FUNCTION 
CODE . 


(Send an XID3 to the DLC manager} one or more retry limits 
need to be applied here. ) 
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Send SEND_XID to the DLC manager. 


(The XID3 sender and receiver have the same value in the Node Identification 


field of their respective XID3s. Generate a new ID number, set the block 
number to either X'000' or X'FFF‘', and send SEND XID.) 


Generate a random ID number. 

Set block number to X'000' or X'FFF'. 

Place the random ID number and block number in SEND_XID. 
Send SEND_XID to the DLC manager. 


C (Role negotiation has determined this node to be primary-nonnegotiable. ) 
Set the Link-Station Role of XID Sender field in SEND_XID to "Sender is 


a Primary Link Station." 
Send SEND_XID to the DLC manager. 
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(Role negotiation has determined this node to be secondary-nonnegotiable. 
If the contact procedure has been started by configuration services, direct 
the DLC manager to accept a mode-setting command. ) 


Set the Link-Station Role of XID Sender field in SENO_XID to "Sender is 
a Secondary Link Station." 
If XID Exchange State field in SEND_XID is set to "Negotiation Proceeding" then 
Send CONTACT_ALS SEC to the DLC manager. 


(Randomizing error--the local and remote node have randomized to the 
same node ID or the nodes are out of synchronization regarding 
the XID3 exchange. Terminate the XID3 exchange. ) 


Append an XID Negotiation Error (X'22') control vector to SEND_XID. 
Send SEND_XID to the DLC manager. 


(Protocol error--terminate XID3 exchange. ) 


Append an XID Negotiation Error (X'22') control vector to SEND_XID. 
Send SEND_XID to the DLC manager. 


(XID3 exchange is complete and the local link station 1s the primary. 
Signal the OLC manager to send a mode-setting command. ) 


If XID Exchange State field in RECVD_XID is set to "Negotiation Proceeding" then 
Send CONTACT_ALS PRI to the DLC manager. 


(Signal the DLC manager to send a null XID.) 


Send NULL_XID to the DLC manager. 


(A mode-setting command was received before the contact phase was started 
by configuration services, or role determination completed before the contact 
phase was started by configuration services and the contact phase has now begun.) 


Set the Link-Station Role of XID Sender field in SEND_XID to "Sender is 

a Secondary Link Station." 

If XID Exchange State field in RECVD_XID is set to "Negotiation Proceeding" then 
Send CONTACT_ALS_SEC to the DLC manager. | 


(This node's role is as the secondary. It sends the secondary XID3, and when in 
the contact phase, signal the DLC manager to accept a mode-setting command. ) 


Set the Link-Station Role of XID Sender field in SEND_XID to "Sender is 

a Secondary Link Station." 

Send SEND_XID to the DLC manager. | 

If XID Exchange State field in XID3 is "Negotiation Proceeding" then 
Send CONTACT_ALS_SEC to the DLC manager. 


Set the Link-Station Role of XID Sender field in SEND_XID to "Sender is 


a Secondary Link Station." 
Send SEND_XID to the DLC manager. 


Send CONTACT_ALS SEC to the DLC manager. 


(Result of a resend with an old node ID. Respond with the randomized 
ID number. Do not compare the current randomized node ID.) 


Send SEND_XID with the randomized ID number to the DLC manager. 
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FSM_XID3_PRI_PROTOCOL 


FUNCTION: This FSM describes the protocol for primary link stations and maintains the 
state for a T2.1 node regarding the exchange of XID3s for the primary link 
station. Additionally, this FSM sends the correct signal to the OLC manager 
that corresponds to the input received. When a protocol violation § 1s 
detected, an XID Negotiation Error control vector is appended to SEND_XID. 


INPUT: The following parameters are the input to this FSM: 


SEND_RECEIVE DIRECTION Indicates whether the XID3 being protocol checked by 
this FSM 1s an XID3 to be sent (5S), an XID3 that has 
been received (R}, or an XIO3 used to initialize this 
FSM to the correct state (I) but that will not be 
sent. 


ROLE_NEGOTIATION_FLAGS When SEND_RECEIVE DIRECTION is equal to receive (R), 
the Link-Station Role of XID Sender field in 
RECVD_XID is examined. This variable takes on the 
value found in that field, t.e., NEGOTIABLE, PRIMA- 
RY _NONNEGOTIABLE, or SECONDARY _NONNEGOTIABLE. 


CR_INDICATOR An indicator that the DLC is using a frame format 
that contains an explicit command/response indicator, 
e.g.» for an ABM DLC. 


SEND_XID A signal to the DLC manager containing the XID3 
I-field to be sent to the adjacent link station. 


NULL_XID A signal that a null XID has been received or that 
one will be sent, depending upon the value of 
SEND_RECEIVE DIRECTION. 


RCV_SET_MODE A signal from FSM_XID3_T2P1_NODE that a mode-setting 
command has been received. 

RESET A signal indicating that the connection should be 
considered to be inactive by this” finite-state 
machine. 

VARIOUS CONDITIONS The results of successful Boolean tests on specific 


fields of SEND_XID and/or RECVD_XID. For example, if 
the Link Station Role of XID Sender field of 
RECVD_XID is set to "Negotiable," then NEGOTIABLE 
will be an input to this FSM. 


OUTPUT: The following parameters are the output from this FSM: 
SEND_XID A signal containing the XID3 I-field to be sent to 


the adjacent link station. In the event of error, an 
XIB Negotiation Error control vector 1s appended to 


SEND_XID. 

CONTACT_ALS_PRI A signal to the DLC manager to send a mode-setting 
command. 

NULL_XID A signal to the DLC manager to send a null XID to the 


adjacent link station. 


Referenced procedures, FSMs, and data structures: 
SEND_XID page 2-36 
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STATE NAMES-~-~->/RESET|WAITING {XID 
INPUTS STATE NUMBERS-->/01 


NEGOTIABLE 
NEGOTIABLE, CR_INDICATOR 
PRIMARY_NONNEGOTIABLE 
SECONDARY_NONNEGOTIABLE 
SECONDARY_NONNEGOTIABLE > 
CR_INDICATOR 
R, NULL_XID 


OomoMoo 
Oo oon oD 


oO © 


» XID3_WITH_CV22 


; 
/ 
/ 
R ~ 
S, XID3_WITH_CV22 a 
S, PRIMARY _NONNEGOTIABLE a 
5) MOLLXID zo 
I, PRIMARY_NONNEGOTIABLE — | 

RCV_SET_MODE : 

ALS_CONTACTED 
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OUTPUT | FUNCTION 
CODE | 


(Send an XID3 to the DLC manager; one or more retry limits 
need to be applied here.) 


Send SEND_XID to the DLC manager. 
(Protocol error--terminate XID3 exchange. ) 


Append an XID Negotiation Error (X'22') control vector to SEND_XID. 
Send SEND_XID to the DLC manager. 


(XID3 exchange ts complete and the local link station is primary. 
Signal the DLC manager to send a mode-setting command. ) 


If XID Exchange State field in SEND_XID is "Negotiation Proceeding" then 
Send CONTACT_ALS_ PRI to the DLC manager. 


(Signal the DLC manager to send a null XID.) 


Send NULL_XID to the DLC manager. 
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FSM_XID3_SEC_PROTOCOL 


FUNCTION: This FSM describes the protocol for secondary link stations and maintains the 
state for a T2.1 node regarding the exchange of XID3s for the secondary Link 
station. Additionally, this FSM sends the correct signal to the DLC manager 
that corresponds to the input received. When a protocol violation is 
detected, an XID Negotiation Error control vector is appended to SEND_XID. 


INPUT: The following parameters are the input to this FSM: 


SEND_RECEIVE_ DIRECTION Indicates whether the XID3 being protocol checked by 
this FSM 1s an XID3 to be sent (5), an XID3 that has 
been received (R), or an XID3 used to initialize this 
FSM to the correct state (I) but that will not be 
sent. 


ROLE_NEGOTIATION_FLAGS When SEND _RECEIVE_DIRECTION is equal to receive (R), 
the Link-Station Role of XID Sender field in 
RECVD_XID is examined. This vartable takes on the 
value found in that field, 1.e., NEGOTIABLE, FPRIMA- 
RY_NONNEGOTIABLE, or SECONDARY_NONNEGOTIABLE. 


CR_INDICATOR An indicator that the DLC is using a frame format 
that contains an explicit command/response indicator, 
e.g.» for an ABM DLC. 


SEND_XID A signal to the DLC manager containing the XID3 
I-field to be sent to the adjacent link station. 


NULL_XID A signal that a null XID has been received or that 
one will be sent, depending upon the value of 
SEND_RECEIVE_ DIRECTION. | 


RCV_SET_MODE A signal from FSM_XID3_T2PI1_NODE that a mode-setting 
command has been received. 

RESET A signal indicating that the connection should be 
considered to be inactive by this finite = state 
machine. 

VARIOUS CONDITIONS The results of successful Boolean tests on specific 


fields of SEND_XID and/or RECVD_XID. For example, if 
the Link-Station Role of XID Sender field of 
RECVD_XID is set to “Sender is a Primary Link Sta- 
tion," then PRIMARY _NONNEGOTIABLE will be input to 


this FSM. 
OUTPUT: | The following parameters are the output from this FSM: 


SEND_XID A signal containing the XID3 I-field to be sent to 

ae _ the adjacent link station. In the event of an error, 
an XID Negotiation Error control vector is appended 
to SEND_XID. 


CONTACT_ALS_SEC A signal to the DLC manager to answer a mode-setting 
command. 


Referenced procedures, FSMs, and data structures: 
SENO_XID page 2-36 
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PROTO {| XIO35 
ERROR | ERROR 


STATE NAMES~---->/RESET | WAITING STATION 


ACTIVE 


STATE NUMBERS-->/01 


NEGOTIABLE 
PRIMARY_NONNEGOTIABLE 
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QUTPUT FUNCTION | | | 
CODE 


(Send an XIOD3 to the DLC manager; one'or more retry limits 
need to be applied here. ) 
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Send SENO_XID to the DLC manager. 


(Protocol error--terminate. XID3 exchange; one or more retry 
limits should be applied here. ) 


Append an XID Negotiation Error (X'22') control vector to SEND_XID. 
Send SEND_XID to the DLC manager. 


c (XID3 exchange is complete and this station is secondary. 
Signal the OLC manager to await a mode-setting command. ) 


If XID Exchange State field in SEND_XID is set to "Negotiation Proceeding” then 
Send CONTACT_ALS_SEC to the DLC manager. 
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NONACTIVATION XID3 FINITE-STATE MACHINES ing that they accept input only after the 
contact phase has completed. 


The two FSMs in this section describe the Both the primary and the secondary nonacti- 
XID3 nonactivation flows. These FSMs have a vation FSMs show XID3s with detected parame- 
protocol boundary with the DLC manager and ter errors as input. An enumeration of 
with the routing and checking logic in CS. format, parameter, and protocol errors 1s 


given tn "XID3 Exchange Errors" on page 2-14. 
The presence of a "LINK NOT ACTIVE” state in 
each FSM has the sole purpose of demonstrat- 
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FUNCTION: This FSM conducts nonactivation XID3 exchanges for primary link stations. 
Unless specifically stated otherwise, the node supports Exchange State indica- 


tors. 
INPUT: The following are the input to this FSM: 
ALS_CONTACTED A signal that the data exchange phase has begun. 


EXCHANGE_NONACT_XID A signal from CP that a nonactivation XID exchange should 
be initiated with the adjacent node. 


NULL_XID A signal from the DLC manager that a null XID from the 
adjacent node has been received. 


RECVD_XID A signal that the DLC manager has received an XID3 from 
the adjacent node. The following information may accompa- 
ny this signal: 


©  ESI_NOT_SUPPORTED--The sender of the XID3 does not 
support Exchange State indicators (ESI). 

° ESI = ACTIVATION_TYPE--The Exchange State indicators 
are set either to ''Prenegotiation Exchange" or to "'Ne- 
gotiation Proceeding." 

° ESI = NON_ACTIVATION--The Exchange State indicators 
are set to "Nonactivation Exchange." 


RESET A signal indicating that the connection should be consid- 
ered to be inactive by this finite-state machine. 


VARIOUS CONDITIONS The results of successful Boolean tests on specific fields 
of SEND_XID and/or RECVD_XID. For example, if the XID3 
Negotiation Error control vector 1s appended to RECVD_XID, 
then CV22_APPENDED will be an input to this FSM. 


OUTPUT: The following are the output from this FSM: 


NONACT_BEGIN A signal to the DLC manager indicating a nonactivation 
exchange 1s about to begin. 


SEND_XID A stgnal to the DLC manager containing the contents of an 
XID3 to be sent to the adjacent node. 


NONACT_XID_EXCHANGED A signal sent to CP to report the completion of the non- 
activation XID exchange. This signal will contain the 
follosing information: 


¢ The adjacent node's CP name. 

° The outcome of the nonactivation XID3 exchange, SUC- 
CESS or FAILURE. The signal of a failure in a nonac- 
tivation XID3 exchange prompts the primary to send the 
DISC command. 

e Indication whether, or not, the adjacent node sends 
the CP name in control vector X'0E'. 

In nodes with NRM DLCs, receipt of this message prompts 

Signaling the DLC manager that the nonactivation XID3 

exchange has been concluded. 


Referenced procedures, FSMs, and data structures: 
NONACT_XID_ EXCHANGED page 2-36 
SEND_XID page 2-36 
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STATE NAMES--~-> ACTIVE AWAITING ERROR 
PRIMARY XID3 
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RECVD_XID, 
FORMAT_OR_PARAMETER_ERROR g 
RECVD_XID, CV22_APPENDED 


OUTPUT FUNCTION 
CODE 


(Cause the DLC manager to send a nonactivation XID3 to the adjacent link 
station. This ts the first XID3 sent by this node in the nonactivation XID3 
exchange. The Exchange State indicator is set to "Nonactivation Exchange" 
and whatever new information that 1s currently Known is included in the 
XID3. For example, if the node's CP name has changed, control vector X'0E' 
carries the new name. ) 


Send NONACT_BEGIN to the DLC manager. 

Set XID Exchange State field in XI03 to "Nonactivation Exchange." 
Send SEND_XID to the DLC manager. 

(A protocol or parameter error is detected. ) 


Append an XID Negotiation Error (X'22') control vector to SEND_XID. 
Send SEND_XID to the DLC manager. 


C (The adjacent node responds to the nonactivation XID3 with an XID3 that 
has ESI set to "Exchange State Indicators Not Supported." 
Further nonactivation exchanges are useless. Configuration services 
routing and checking logic is informed via NONACT_XID_EXCHANGED. ) 


Set NONACT_XID_EXCHANGED .CPNAME_IN_CVOE to NO. 

Set NONACT_XID_EXCHANGED.EXCHANGE_STATUS to SUCCESS. 

Send NONACT_XID_EXCHANGED to configuration services 
routing and checking logic. 


(Nonactivation XID3 exchange is completed. ) 


Set NONACT_XID_EXCHANGED.CPNAME_IN_CVOE to YES. 
Set NONACT_XID_EXCHANGED.CPNAME to adjacent node's CP name. 
Set NONACT_XID_EXCHANGED.EXCHANGE_STATUS to SUCCESS. 
Send NONACT_XID_EXCHANGED to configuration services 
routing and checking logic. 


(The unsuccessful conclusion of the nonactivation XID3 exchange is reported 
to configuration services routing and checking legic to send DISC.) 


Log error. 

Set NONACT_XID _EXCHANGED. EXCHANGE_STATUS to FAILURE. 

Send NONACT_XID_EXCHANGED to configuration services 
routing and checking logic. 
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FSM_XID3_NACT_SEC 


FUNCTION: This FSM conducts nonactivation XID3 exchanges for secondary link stations 
that support Exchange State indicators. 


INPUT: The following are the input to this FSM: 
ALS_CONTACTED A signal that the data exchange DLC phase has begun. 
NULL_XID A signal from the DLC manager that a null XID has been 
received. 
RECVD_XID A signal that the DLC manager has received an XID3 from 
the adjacent node. The following inputs may accompany 
RECVD_XID: 


e  ESI_NOT_SUPPORTED-The sender of the XID3 does not sup- 
port Exchange State indicators (ESI). 

e ESI=ACTIVATION_TYPE--The Exchange State indicators are 
set to "Prenegotiation Exchange” or to "Negotiation 
Proceeding." 

ESI=NON_ACTIVATION--The Exchange State indicators are 
set to "Nonactitvation Exchange." 

e ABM_DLC--The link station supports ABM/ABME protocols. 


RCV_NON_XID A signal that the DLC manager has received RR, RNR, or an 
I-frame with the Poll bit set during a nonactivation XID3 
exchange 

RESET A signal indicating that the connection should be consid- 


ered to be inactive by this finite-state machine, e.g., 
DISC has been received by the DLC manager. 


VARIOUS CONDITIONS The results of successful Boolean tests on specific fields 
of SEND_XID and/or RECVD_XID. For example, if a format or 
parameter error is detected in RECVD_XID, then FOR- 
MAT_OR_PARAMETER_ERROR will be an input to this FSM. 


OUTPUT: The following are the output from this FSM: 


NONACT_BEGIN A signal to the DLC manager § indicating a nonactivation 
exchange has begun. 


SEND_XID A signal to the DLC manager containing the contents of an 
XID3 to be sent to the adjacent node. 


NONACT_XID_EXCHANGED A signal sent to CP to report the completion of the non- 
activation XID exchange. This signal contains the follow- 
ing information: 


e@ The adjacent node's CP name. 

e The outcome of the nonactivation XID3 exchange, SUC- 
CESS or FAILURE. In an NRM/NRME secondary without a 
response opportunity, the link station awaits the DISC 
command from the primary after the nonactivation XID3 
exchange has failed. When failure notification occurs 
during an NRM/NRME response opportunity, the secondary 
station initiates disconnection of the link con- 
nection, preferably by resetting the FSM and by using 
the response opportunity to send DM. In = an ABM/ABME 
secondary, failure notification prompts sending of the 
DISC command. 

In NRM/NRME link stations, NONACT_XID_EXCHANGED prompts a 

Signal to the DLC manager that nonactivation XID3 exchange 

has been completed. 


Referenced procedures, FSMs, and data structures: 
NONACT_XID_EXCHANGED page 2-36 
SENOD_XID | page 2-36 
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STATE NAMES-~---> ACTIVE IN ERROR 
| SECONDARY NONACT | 
STATION EXCHANGE 
STATE NUMBERS~-> 02 04 


NULL_XID 
RECVD_XID, ESI_NOT_SUPPORTED 
RECVD_XID, ESI=ACTIVATION_TYPE 


RECVD_XID, CV22_APPENDED, ASM_DLC 
RECVOD_XID, CV22_APPENDED 


RECVD_XID,», ESI=NON_ACTIVATION, 
ABM_OLC 


RECVD_ XID, ESI=NON_ACTIVATION, 


RN IAL Fle IVE ONE i a 


OUTPUT | FUNCTION 
CODE 


(Cause the DLC manager to send a nonactivation XI03 to the adjacent Link 
station. This is the first non-null XID sent in the nonactivation XID3 
exchange. The Exchange State indicators are set to "Nonacttvation Exchange” 
and whatever new information that is currently Known should be tncluded tn 

the XID3. For example, if the node's CP name has chanced, control vector X'O0E' 
should reflect this fact. At this time, the link station is informed via 
NONACT_BEGIN that a nonactivation XID3 exchange is taking place. ) 


Send NONACT_BEGIN to the OLC manager. 
Set XID Exchange State field in XID3 to “Nonactivation Exchange.” 
Send SEND_XID to the DLC manager. 


(A protocol error occurs or a parameter error in the received XID3 has been 
detected. ) 


Append an XID Negotiation Error (X'22') control vector om SENOD_XID. 
Send SEND_XID to the DLC manager. 


(Respond with the last XID3 that was sent.) 
Send SEND_XID to the DLC manager. 
E 


(The nonactivation XID3 exchange is concluded. ) 


Set NONACT_XID_EXCHANGED.CPNAME to adjacent node's CP name. 

Set NONACT_XID_EXCHANGED.EXCHANGE_STATUS to SUCCESS. 

Send NONACT_XID_EXCHANGED to configuration services 
routing and checking logic. 


(A secondary ABM/ABME Link station has received an XID3 with a control vector X'22' 
appended. Internal disconnection procedures can be started. These procedures 
include prompting the DLC manager to send DISC by means of NONACT_XID_EXCHANGED. ) 


Log error. 

Set NONACT_XID_EXCHANGED.CPNAME to adjacent node's CP name. 

Set NONACT_XID_EXCHANGED.EXCHANGE_STATUS to FAILURE. 

Send NONACT_XID_EXCHANGED to configuration services 
routing and checking logic. 
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(RESET has been received after an error has been detected. Notify 
configuration services of the nonactivation exchange failure. ) 


Log error. 

Set NONACT_XID_EXCHANGED .EXCHANGE_STATUS to FAILURE. 

Send NONACT_XID_EXCHANGED to configuration services 
routing and checking logic. 


(An ABM secondary concludes the nonactivation exchange. It sends its 
nonactivation XID3 response to the primary and informs configuration 
services that the exchange is complete. ) 


Send SEND_XID to the DLC manager. 
Set NONACT_XID_EXCHANGED.CPNAME to adjacent node's CP name. 
Set NONACT_XID_EXCHANGED.EXCHANGE_STATUS to SUCCESS. 
Send NONACT_XID_EXCHANGED to configuration services 
routing and checking logic. 


(While in the error state an RR, RNR or I-frame (all with the poll bit 
set) arrives, the NRM secondary station logs the error and sends 
notification of the nonactivation exchange error to configuration 
services. This prompts the secondary disconnection of the link 
connection. ) 


Log error. 

Set NONACT_XID_EXCHANGED .EXCHANGE_STATUS to FAILURE. 

Send NONACT_XID_EXCHANGED to configuration services 
routing and checking logic. 
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FSM COMMON DATA STRUCTURES 


The folloming data structures are referenced 
by multiple FSMs. 


SEND_RECEIVE_DIRECTION 


A variable used internally by the link activation FSMs. A value of S (Send) indicates 


that the FSM will get its input from SEND_XID; a value of R (Receive), that the FSM will 
get its input from RECVD_XID; and a value of I (Initialize), that the input will be used 
to initialize an FSM but will not be sent. 


SEND_RECEIVE_DIRECTION: possible values: S (Send), R (Receive), I (Inttialize) 


COMMAND_RESPONSE_RCV_INDICATOR 


A variable used internally by FSM_XID3_T2P1_NODE to determine whether RECVO_XID is to be 
interpreted as a command or response. 


COMMAND_RESPONSE_RCV_INDICATOR: possible values: COMMAND, RESPONSE 


NONACT_XID_EXCHANGED 


A signal to configuration services to report the completion of a nonactivation XID3 
exchange. This signal will prompt configuration services to inform other components of 
the node, e.g.» DLC manager, that the nonactivation XID3 exchange has completed and to 
pass on any new information obtained in the course of the exchange, e.g., the CP name of 
the adjacent node. 


NONACT_XID_EXCHANGED: sO ‘ 
-EXCHANGE_STATUS: possible values: SUCCESS, FAILURE 
CPNAME_IN_CVOE: possible values: YES, NO 
CPNAME: possible values: adjacent node's CP name 


SEND_XIO 


A signal that contains the XID3 I-field to be eventually sent to the DLC manager. Other 


information used to identify the link station may be included if needed. In this model, a 
separate set of FSMs exists for each link station. 


SEND_XID 
XID3 I-field being sent. 
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SEND_XID 


RECVD_XID 


A signal that contains the XID3 I-field sent by the adjacent node. Other information used 
to identify the link station may be included if needed. In this model, a separate set of 
FSMs exists for each link station. 


RECVD_XID 
XID3 I-field being received. 
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CHAPTER 3. ADDRESS SPACE MANAGER 


“Address Space Manager (ASM)" in Chapter 1 
provides a summary of address space manager 
(ASM) funetion. This chapter covers the spe- 
cifics of local-form session identifier 


FUNCTIONAL DESCRIPTION 


NODE ADDRESS CONTROL 


For an LU to initiate a session mith a part- 
‘ner LU, it must have a local-form session 
identifier (LFSID) and an identifier for the 
PC instance that 15 associated with the link 
for the node containing the partner LU. The 
LU requests the PC instance identifier from 
SS, using the partner LU name and mode name, 
and then uses that identifier to request an 
LFSID from ASM. For each PC instance, ASM 
maintains an address space and a list of 
LFSIDs in use; on receiving the request from 
the LU, ASM assigns an unused LFSID from the 
address space associated with the PC instance 
identi fier. The LFSIO and path control 
instance identifier uniquely specify the ses- 
sion within the node and accompany all mes- 
sages routed between the LU and the path 
control instance. | 


Local-Form Session Identifier (LFSID) 


The LFSID 1s composed of: 


© A l-bit OAF'-DAF' <Assignor = § indicator 
(ODAT). 


An ODAI value indicates the half of the 
address space from which the BIND sender 
is selecting LFSIDs. It is determined as 
follows: the node containing the primary 
link station on the link uses an ODAI of 
value 0; an ODAI value of 1 indicates 
that the BIND sender is in the node con- 
taining the secondary link station on the 
link. 


e)6=—OCO A 16-bit session identifier composed of: 


- An 8-bit session identifier high 
(SIOH) field 


- An 8-bit session identifier low 
(SIDL) field 


See "Chapter 4. Path Control" for a dis- 
cussion of how the LFSID is encoded in the 
ODAI, OAF', amd DAF' fields of the FID2 
transmission header (TH). 


(LFSID)} assignment, as well as ASM'’s inter- 
action with other components of the T2.1 
node. 


Address Space Management 


ASM is notified by CS when a link (identified 
by its associated PC instance identifier) is 
activated or deactivated; ASM then creates or 
destroys, respectively, the appropriate 
address space. LFSIDs from this” address 
Space are assigned in a sequentially increas- 
ing order, with re-use of previously released 
LFSIOs. Re-used LFSIDs are assigned begin- 
ning with the lowest available address. 


The LFSID assigned to each session is valid 
only for the duration of the session, and 
therefore the relationship between LUs and 
LFSIDs as encoded in the FID2 TH 1s dynamic. 


The following rules apply for the 16-bit ses- 
sion identifier address assignment of LU-LU 
sessions for BINDs sent by T2.1 nodes on a 
specific Link (where, for example, a value of 
X'OLFE' indicates a SIDH of X'Ol1' and a SIDL 
of X'FE'). 


e X'0000'~-X'0100' reserved 
e X'OLOL'-X'FEFF' used for LU-LU sessions 
e X'FFOO'-X'FFFF’ reserved 


Implementations of T2.1 nodes not at the cur- 
rent level of SNA may use an assignment algo- 
rithm different from that described above; 
1.@.,  mumbers may not be sequentially 
assigned as the assignment algorithm 
describes. 


NON-SESSION TRAFFIC ROUTING 


ASM routes session-activation and -deacti- 
vation requests and responses (1i.e., BIND or 
UNBIND) between LUs and the appropriate PC 
instance. The address spaces maintained by | 
ASM for the path control instances are used 
in providing the services described below. 


Routing from LU to PC 


when ASM receives a BIND or UNBIND from an 
LU, it routes the BIU to the appropriate path 
control instance. 
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Routing from PC to L 


een 


When ASM receives a RSP(BIND), UNBIND, or 
RSP(UNBIND) from PC, it uses the sppropriate 


address space and LFSID to route the BIU to 


the proper LU. If the LFSID is unknecwn: 
° If the BIU is a response, ASM discards 
the BIU and ignores it. 


e If the BIU is an UNBIND, ASM sends a pos- 
itive RSPC(UNBIND) back to the originator 
LU. 


ASM examines each BIND received from PC and 
does internal routing of it to the proper LU 
using the network services SLU Name field 
(see "Request/Response Units" in Appendix B 
for format details) in the BIND request. 


The network services SLU Name field may be 
either a network-qualified name or an unqual- 
ified name. The unqualified name its a l- to 
8-byte type-A symbol-string (SNA Transaction 
Programmer's Reference Manual for LU Tyre 6.2 
defines type-A symbol strings) that uniquely 
identifies the SLU within its network. The 
PLU may include the network identifier of the 
SLU in the name field as well. When this is 
done, the network identifier (also a 1l- to 
8-byte type-A symbol string) 1s prefixed to 
the unqualified SLU name and separated by a 
period (X'4B'). Thus, the network-qualified 
name 15 of the form "NETID.SLUNAME” where 
“NETID."" 18 opttonal—and may be 1 to 17 
bytes in length. Nodes at the current level 
of SNA do not send network-qualified SLU 
names, but are able to receive and tnterpret 
them. 


The SLU name is always present in BINDs from 
nodes at the current level of SNA. If the 


ASM makes a number of checks for error condi- 
tions upon receipt of a BIND; a complete list 
of these conditions, with corresponding sense 
data, is given below. See “Sense Data" in 
Appendix B for details. : 


The LFSID received is already in use 
(X'08150004' ). 


® An invalid LFSID was received 
(X*800F0000' ). 
® Invalid address combination 


(X*800FO001'). 


¢ No memory available for LFSID tables 


(X'08120007" ). 


SLU name is not recognized as being in the 
node, ASM constructs a negative RSP{(BIND) 
with sense data X'80060000' and returns it to 
the PLU. For optional support of nodes that 
do not include the SLU name in the BIND 
request, ASM in the receiving node may use a 
local default SLU name. If no default SLU 
name its provided and no SLU name is in the 
BIND, a negative RSP(BIND) with sense data 
X'80040000' is sent back to the PLU. 


ASM in the receiving node also determines if 
the LFSID in the BIND request is already in 
use in the corresponding address space. 


e If it is, ASM constructs a negative 
RSP(BIND) with sense data X'08150004¢'. 


e If it is not, ASM makes an association 
between the LFSIO and the LU named in the 
SLU Name field given in the BIND request, 
marks the LFSID "tn use,'* and routes the 
BIND request to the LU. 


If the BIND is an EXCEPTION REQUEST (EXR, a 
request RU containing sense data), ASM con- 
structs the appropriate negative response 
(with tine same sense data as in the EXR) and 
sends it to the originator LU. 


Route-Outage Notification 


When a route becomes inactive because of a 
link outage, CS informs ASM. ASM then noti- 
fies all affected LUs of the outage and deac- 
tivates the address space associated with the 
link. The LUs are responsible for recovery 
and notification of all affected LU ccomro- 
nents and transaction programs. 


° No buffer available to receive the BIND 
(X°'0812000D'). 


e ASM is unable to route the BIND to the LU 
because the LU is not active 
(X'08010000' ). 


e Unknown SLU name in the BIND, or the BIND 
has no SLU name and the node has no 
default SLU name (X‘'&0040000'). 


] 


e The SLU Name's length exceeds the remain- 
ing length of the BIND (X'0835nnnn'), 
where nnnn is the offset in bytes to the 
SLU Name Length field. 
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CHAPTER 4. PATH CONTROL 


INTRODUCTION 
The path control (PC) component of a T2.1 One PC instance exists per link and, as shown 
node deltvers message units between LUs in in Figure 4-1, each PC instance consists of a 
the node and other LUs within or outside the manager and element component. 


node. It enables an LU to exchange message 
units without Knowledge of the actual link 


configuration. 
A 
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Figure 4-1. Structure of Path Control: The numbered arrows show the routing of different kinds of 
traffic: 


1. Seesion traffic 
2. Non-session traffic (BIND, RSP(BINO), UNBINO, RSPCUNBIND) ) 
3. Create and destroy signals 


Note: CP.CS and CP.ASM refer, respectively» to the CS and ASM components contained 
within the CS component. 
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The path control manager has PC session acti- 
vation and deactivation responsibilities. 
ASM sends session-connection and -discon- 
nection information to a path control manag- 
er, causing it to change the set of 
half-sessions connected to the path control 
Instance. 


The path control element is responsible for: 


e Message routing: Route messages from 
path control to LU and DLC components. 


In order to perform its routing func- 
tions, path control maintains anareness 
of the half-sessions with which it can 
exchange message units. Tables showing 
the relationships between these 
half-sessions in the node and LFSIDs are 
used to map incoming and outgoing address 
fields of the TH. : 


e Message transformation: Convert message 
units received from DLC to a form that 


MESSAGE-UNIT TRANSFORMATION AND ROUTING 
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MESSAGE-UNIT TRANSFORMATION 


A path control instance exchanges basic 
information units (BIUs) with LUs and basic 
transmission units (BTUs) with data link con- 
trol. In the T2.1 node, the BTU and path 
information unit (PIU) are the same, since no 
PIU blocking is done. A BIU may be converted 
into one or more PIUs by segmenting it and 
attaching a FID2 TH field to each segment. 
Transforming one or more PIUs into a single 
BIU involves stripping off the THs and per- 
forming segment assembly. 


A complete description and discussion of the 
FID2 structure can be found in SNA Reference 


Summary. 


MESSAGE-UNIT ROUTING 


The primary purpose of path control is to 
convey message units between two LUs. If 
they are in the same node, path control 
recetves a BIU from one LU and delivers it to 
the other. If they are in different nodes, 
the path control is distributed between the 
sending node and the recetving node, as 
described below. 


Transmitting BTUs between Nodes 


The path control in a sending node takes a 
BIU from the LU (session traffic) or ASM 
(non-session traffic) and transmits the 
resulting BTUs (fone PIU per BTU) to the 
remote node via the associated adjacent Link 
etation. Segmenting of session traffic 


can be processed by the CP and LUs; con- 
versely, convert messages received from 
the CP and LU to a form that can be proc- 
essed by DLC. 


®e Segment generation: Generate BIU seg- 
ments for cutbound session traffic when 
required (done only if segment generation 
is supported by the node). 


® Segment reassembly: Reassemble BIU seg- 
ments into BIUs from inbound message 
units shen required (done only when seg- 
ment reassembly is supported). 


® Error checking: Perform error checking 
(e.g., to find TH errors) on message 
units received from data link control. 


The sections below provide more detail on 


message-unit transformation, segmentation, 
and error checking performed by path control. 


request BIUs into one or more PIUs may be 


done if required and supported by the node. 


Routing Received BTUs to L 


The path control in a receiving node receives 
BTUs from data link control, reassembles 
(session traffic) BIU segments within them 
(when reassembly is supported), and routes 
the extracted (shole) BIUs either to the 
appropriate half-session (for session traf- 
fic) or ASM (for non-session traffic). 


Path control identifies non-session traffic 
by the RU Category field in the RH and the 
session-activation or -deactivation request 
code in the RU; path control routes session 
traffic to half-sessions by deriving an LFSID 
from the TH, as described below. 


Each session is associated with the 17-bit 
LFSID (composed of ODAI, SIDH, and SIDL 
fields), which is assigned by the node con- 
taining the primary LU. (See "Chapter 3. 
Address Space Manager" for a discussion of 
the LFSID, ODAI, SIOH, and SIDL fields.) 


The LFSID is conveyed between toro T2.1 path 
controls in the ODAI, OAF', and DAF' fields 
of the FID2 TH. The fields of the FID2 TH 
are set according to the following rules: 


e OOAI—This field contains the ODAI of the 
BIND sender. 


e DAF'—This field contains the SIDL for 
all PIUs that flow in the direction of 
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the BIND, and the SIDH for all PIUs that 
flow in the direction of the RSP(BIND). 


e OCAF'—The OAF' field contains the SIDH 
for all PIUs that flow in the direction 


SEGMENTATION 


Session traffic (neither BIND nor UNBIND) is 
segmented by T2.1 nodes, if segmenting is 
supported by the node. Segmenting of BIUs 
into smaller BIU segments is performed by 
path control in order to transmit message 
units longer than the maximum-size BTU 
allowed by a particular link. These segments 
are reassembled into whole BIUs at the path 
‘control of the partner node. 


A normal-flow request BIU can be segmented; a 
response BIU can not. When PC receives a BTU 
from DLC, the Mapping field (MPF) in the TH 
indicates whether the BTU contains a whole 
BIU or a first, middle, or last segment of a 
BIU. The MPF of a BTU containing a response 
BIU will always indicate the presence of a 
whole BIU. 


A first segment always contains at least ten 
bytes of BIU data. The minimum size of 10 
accommodates EXRs, which contain a 3-byte RH 
field, a 4-byte sense data field, and; 
optionally, 1 byte of RU data. BIUs shorter 
than 11 bytes are never segmented. 


of the BIND, and the SIDL for all PIUs 
that flow in the direction of § the 
RSP( BIND). 


SUPPORT OF SEGMENTING 


Segmenting 1S composed of segment generation 
and segment reassembly. Segment generation 
1S a prerequisite for segment reassembly, and 
any node that supports segment reassembly 
reassembles on a session basis. 


SEGMENT GENERATION 


A sender segments a BIU if the link receive 
buffer itn the adjacent node jis not large 
enough to allow the node to receive the whole 
BIU, i.e., the length of the BIU is greater 
than the adjacent node's maximum receive BTU 
size would allow. If the length of the BIU 
is less than or equal to that allowed by the 
adjacent node's maximum receive BIU size, the 
BIU 1s sent whole. 


BIU 
a ae 


|<------ maximum BTU size ----- >| 


NE endaags cae 
oe 6. 
hint ae. ee 


Note: The RU data in the middle and last BIU segments may be three bytes longer than 
the RU data in the first segment, because each first BIU segment includes the RH. 


Figure 4-2. Length of Segments 


First BIU segment (RH + RU data) 


PIUs 
Middle BIU segment (RU data) 


Last BIU segment (RU data) 


Segments are generated as illustrated in Fig- 
ure 4-2. The Mapping field in the TH (for 
details of the Mapping field, see SNA Refer- 
ence Summary) of each PIU ts set to indicate 
whether the BTU (1.e., PIU) contains the 
first, middle, or last segment of the BIU. 
If the BIU has not been segmented, the map- 
ping field indicates that the BTU contains a 
whole BIU. Path controls of nodes not sup- 
porting segmenting make a mandatory check for 
a mapping field value that does not indicate 
a whole BIU; if such a value 1s found, path 


control sends a negative response with sense 
data. 


All segments of a BIU have the same sequence 
number . | 


The length of each PIU carrying a BIU segment 
is always equal to or less than the lesser of 
the node's maximum send BTU size and the 
adjacent node's maximum receive BTU size (as 
specified in XID3}. 
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SEGMENT REASSEMBLY 


Segment reassembly is done according to the 
address in the TH of each PIU. Path controls 
that support segment reassembly do so on a 
per session basis in order to reassemble seg- 
ments interleaved from different sessions. 


Base Maximum BTU Sizes 


SNA specifies an implementation restriction 
that requires LUs to be able to support an RU 
size of 256 bytes when sending and receiving 
RUs. (In some products, network owners may 
set the RU size to other values; however, the 
underlying product implementation must always 
permit the network owner the choice of 256.) 
With a FID2 TH, an RU size 256 translates to 
a base maximum BTU size of 265 (6-byte FID2 
TH plus 3-byte RH plus 256 bytes of RU). 
Support of the base BTU size does not pre- 
clude support of other BTU sizes. 


Sequenting Parameters 


The parameters involved in setting up seg- 
menting are found in three places: system 
definition, XI03, and BIND. These parame- 
ters, grouped by location, are: 


° System definition 


- Maximum Send BTU size 
= Maximum Recetve BTU size 


° In XID3 
—- Maximum Receive BTU Size field of 
sending node 
e In BIND 


- PLU Maximum Send RU Size field 
= SLU Maximum Send RU Size field 


The receiving path control checks for the 
following errors in BIUs, which are shown 
with their associated sense data. See ‘Sense 
Data" in Appendix B for details. 

¢ Improper FID type (X‘'80060000' ) 

© Incorrect TH length (X'800B0000' ) 

® Incorrect RH length (X'40050000' ) 


® Incorrect RU length for session control 
RUs (X'10020000' ) 


© Segmented BIU received by a node that 
does not support segmenting (X'80070001' ) 


~- Whole-BIUs Required indicator 


For a particular adjacent link station, a 
node may support two maximum BTU sizes: max- 
imum receive BTU size, which is the largest 
BTU the node can receive; and, optionally, 
maximum send BIU size, which is the largest 
BTU size it can send. The two need not be 
equal. If a node has more than one adjacent 
link station, it may support a different max- 
imum send and receive BTU size for each one. 
When connecting to another node, a node spec- 
ifies its own maximum receive BTU size in 
XID3. Any BIU larger than this size cannot 
be sent to the node wnless it is segmented. 
A node's maximum send BTU size is an internal 
parameter, which is not made known to adja-~. 
cent nodes. 


At session activation, a T2.1 node LU speci- 
fies in BIND the maximum RU size it can 
receive on the session. This size is not 
directly related to the maximum BTU stze DLC 
can receive, but if the maximum RU size Is 
larger, the adjacent node segments BIUs to 
fit or, if segmentation is not supported, 
sends smaller BIUs. 


Tuo maximum RU size fields exist in BIND: 
to the PLU maximum receive RU size) and PLU 
Maximum Send RU Size (shich corresponds to 
the SLU maximum receive RU size). A PLU 
specifies in a BIND request both the PLU and 
SLU maximum send RU sizes. The SLU may nego- 
tiate either of these downward (or upward to 
256) tn the BIND response. ) 


If segment generation is not supported, the 
maximum RU sizes are always less than or 
equal to the DLC's maximum BTU size minus the 
length of the TH and RH. Negotiation of max- 
imum RU sizes may be required to avoid seg- 
ment generation when nodes cannot receive 
segments. 


A T2.1 node uses the Whole-BIUs Required 


indicator in BIND to indicate whether it can 
receive segments over the session. 


¢ Non-matching sequence numbers in related 
segments (X'80070000' ) 


e §€6First segment too short (X*80070000° } 
® Segments out of sequence (X‘'80070000') 


® Sesston address not 
(X'80050000' ) 


recognized 


If an erroneous request BIU indicates that an 
error response is required, a negative 
response is returned to the sender, if possi- 
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ble.! Whether or not a response is required, response, the receiving T2.1 node will send 
the error is logged and the erroneous BIU jis UNBIND. 
discarded. On receipt of a negative 


1 In some cases» e.g.» a garbled TH or RH, a node will not be able to send a response. 


Chapter 4. Path Control Q-5 © 
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APPENDIX A. FSM NOTATION 


A finite-state machine (FSM) 1s a combination 
of processing and memory, where the memory 
consists of the state of the FSM. The state 
can take one of a small number of named val- 


ues (the state mames). An FSM is defined by | 


a matrix that lists the states and specifies 
the processing to be performed when the FSM 
is called. This processing typically depends 
on the current state of the FSM and on the 
input passed to the FSM, and may change the 
FSM state (resulting in a state transition) 
and produce output. Within this matrix defi- 
‘nition, each state is given a number as well 
as its name, for notational convenience. 


A number of alternative FSM definitions may 
be grouped together as a generic FSM, the 
definition to be used being assigned dynam- 
ically. The assignment of a particular defi- 
nition to be used at a given time is called 
the binding of the generic FSM. A generic 
FSM is indicated by a prefixed pound sign 
(#). 


Within FSMs», a naming convention using peri- 
ods (.) Its employed to denote subcomponents 
of a structure. Another special character, 
the underscore (_}, appears in names to indi- 
cate a name phrase rather than decomposition. 


The following operations may be performed on 
an FSM: 


®* Call. Processing is performed as defined 
in the FSM definition for the existing 
combination of current state and input. 
This may involve a state transition. 


e State test. The current state of the FSM 
is tested for equality or inequality with 
a specified value. No state change 
occurs. 


An FSM is represented by a state-transition 
matrix. The syntax of the state-transition 
matrix FSM definition ts shomm in Figure A-! 
om page 2. The column headings give the FSM 
state names, while the row headings name the 
inputs to the  FSMs. The matrix ele- 
ments—(row,column) intersections—define the 
state transitions and output actions. 


Horizontal lines are used to group input 
lines together to improve readability. Their 
location has no bearing on the FSM function. 
For compactness, mnemonic abbreviations are 
used in the matrices. 


An FSM comes into existence initialized to 
state 1. If another state is to be the ini- 
tial state, the FSM is initialized explicitly 
by calling the FSM with an appropriate sig- 
nal. 


Calling an FSM executes the FSM; j.e., an FSM 
action code is selected based on the current 
state of the FSM and the input line that is 
true. The input line evaluation uses the 
parameters or signal passed to the FSM. The 
FSM is scanned for a true input line from top 
to bottom of the matrix. No more than one 
input line in a matrix is true during a scan. 


If the next-state indicator is a number n,> 
the FSM enters state n. If the next-state 
indicator 3S a cannot-occur indicator (/), 
this is an execution-time error; calls of the 
FSM cannot encounter this indicator because 
previous logic has filtered out the input for 
that state of the FSM. 


If no input line is true, the call of the FSM 


acts as if a no-state-change indicator (-) 
were encountered. 
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fname: 


STATE NAMES~--~--> 


INPUTS STATE NUMBERS-~-> 


Legend: 
{ } = optional parameter 
fname = FSM name 


snam = state name component 
= state number 


é 


= input condition name 
ac = action code 
= output code 
An action code (ac) has the follosing possible syntax: 


nloc] normal state transition to state n (corresponding to some snus) 
and execution of the function identified by oc 


-loc] same-state transition—remain in the same state 
/ "cannot occur" condition, no state change 


Figure A-1. Syntax of an FSM State-Transition Matrix 
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APPENDIX B. XID, RUS, CONTROL VECTORS, AND SENSE DATA 


Certain formats and fields used by T2.1 nodes have been updated from SNA Reference Summary; the updated 
formats are provided here. Sense data provided here are those that appear in the text of this book. 


T2.1 nodes ignore unrecognized fields and control vectors received in XID, BIND, UNBIND, RSP(BIND), and 
RSP(UNBIND), %.e., reserved bits are not checked and unknown control vectors do not cause error condi- 
tions. T2.1 nodes do not echo received unrecognized fields and control vectors. 


EXCHANGE IDENTIFICATION (XID} INFORMATION FIELDS 


SS IEEE EATEN | Eee 0 GEE 


0 - bits 0-3, format of XID I-field: 
X'3' variable format (for T2.1 to T2.1 and T2.0 to T4/15 node exchanges): bytes 0-p 
are included 
bits 4-7, type of the XID-sending node: 


X'2' T2 
1 Length, in binary» of variable-format XID I-field (bytes 0-p); reserved for fixed-format XID 
I-field 
2-517 Node Identification 
2-5 bits 0-11, block number: an IBM product specific number; see the individual product specifica- 


tions for the specific values used 
Note: The values all O's and all 1's indicate that bytes 2-5 do not contain a 
unique node identifier. 
bits 12-31, ID number: a binary value that, together mith the block number, identifies a spe- 
cific station uniquely within a customer network installation; the ID number can be 
assigned in various ways, depending on the product; see the individual product 
specifications for details 
Note: khhen the Block Number field does not contain all 0's or all 1's» a value of 
all O's in the ID number indicates that no ID number has been assigned. 
Note: For XID format 3, the contents of bytes 2-5 of the node identification field are used 
in some instances as a role-negotiation-value to resolve contention in protocol roles of nodes, 
e.g.» primary/secondary DLC roles or the ODAI value to be appended to the (OAF', DAF') values 
assigned at a node. When a role-negotiation value 1s needed and the node does not supply a 
unique node identification value, it supplies a random value in the ID number field. 
® End of Format 0 


6-p Format 3 Continuation 
6-7 Reserved 
8-9 Characteristics of the node of the XID sender: 
bit 0, INIT-SELF support: 
0 INIT-SELF may be sent to the XID sender 
Note: If the XID sender does not contain an SSCP, it forwards any INIT-SELF received 
to the proper node for processing, which returns the response to the originator of 
the request. . 
1 INIT-SELF (and character-coded logon) cannot be sent to the XID sender 
Note: For bits 0-1, the value 11 is reserved. 
bit 1, stand-alone BIND support: 
0 BIND may be sent to the XID sender without a prior INITIATE sequence 
1 BIND may not be sent to the XID sender 
Note: For bits 0-1, the value 11 is reserved. 
bits 2-3, retired, set to ll 
bits 4-7, FID types that the node supports on this Link: 
X'O' FID2 | 
bit 8)» retired 
bits 9-1ll, reserved 
bits 12-13, XID exchange state: 
00 exchange state indicators not supported (set only by implementations not at the 
current level of SNA) 
01 negotiation-proceeding 
10 prenegotiation exchange 
ll nonactivation exchange 
bits 14-15, reserved 
10-16 Reserved 
i? DLC type: 


X'Ol' SDLC Conly value defined) 
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18-n 
18 


19 
19 


20 
21-22 


23 


B-2 


OLC Dependent Section : 
Length, in binary, of the OLC Dependent Section field (Length field includes itself in the 
length speci fied. ) 
Link Station and Connection Protocol Flags 
bit 0, reserved | 
bit 1, ABM support indicator: 
0 XID sender cannot be an ABM combined station 
1 XIO sender can be an ABM combined station 


bits 2-3, link-station role of XID sencer: 


00 sender is a secondary link station (nonnegotiable) 
01 sender is a primary Link station (nonnegotiable) 
10 reserved ; 
11 negotiable (primary or secondary capability) . 
Note: For ABM stations, the value of bits 2-3 is used only for the purposes of 
OAF'-DAF' assignment and deciding which node sends the Set Mode command. 
bits 4-5, reserved 
bits 6-7, link-station trarnsmit-receive capability: 
00 tuo-way alternating 
01 two-way simultaneous 
Reserved 
Maximum BTU length that the XID sender can receive: 
bit 0, format flag: 
0 bits 1-15 contain the maximum BTU length (only value defined) 
bits 1-15, maximum BTU lengths in binary 
bits 0-3, reserved 
bits 4-7, SDLC command/response profile: 
X'O’ SNA Link profile (only value defined) 
Note: These profiles refer to the mandatory command/response support on an SDLC 
link, as follows: 


® For an SOLC link in normal response mode (NRM/NRME), having a point-to-point 
or multipoint configuration (determined from system definition), the support 
required is: ; 
Commands Res ses 


T-frames I-frames 


RR RR 
RNR RNR 
Test Test 
XID XID 


SNRM/SNRME UA 
Disconnect OM 

- RD 

- Frame Reject 
Reject Reject 


Note 1: The RO response is sent by the secondary station if and only if CS 
s decided to deactivate the link. 


ha 
Note 2: Reject is required only if both sender and receiver have tro-nay 
imultaneous: transmit-receive capability. 


wi 


® For an SOLC link in normal response mode (NRM), having a loop configuration 
(determined from system definition), the support required is: 


Commands Responses 


I-frames I-frames 


RR RR 

RNR RNR 

Test Test 

XID XID 

SNRM UA 
Disconnect OM 

UP - 

- Frame Reject 
Configure Configure 
- Beacon 

~ RD 
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Note: The RD response is sent by the i station if and only if CS has 
decided to deactivate the link. 


® For an SDLC link tn asynchronous balanced mode (ABM) (determined from the 


Link-Station Role of XID Sender field), having a point-to-point configura- 
tion, the support required is: 


Commands Res es 


RR RR 

RNR RNR 

Reject Reject 

SABME UA 
Disconnect DM 

Test Test 

XI XID 

- Frame Reject 


Note 1: All commands and responses are transmitted and received in two-octet 
format (extended control field). 


Note 2: Frame Reject is not required to be transmitted; receive capability 
1S required. 


bits 0-1, reserved 

bit 2, SOLC initialization mode options: 
0 SIM and RIM not supported 
1 SIM and RIM supported 

bits 3-7, reserved 

Reserved 

bit 0, reserved 

bits 1-7, maximum mumber of I-frames that can be received by the XID sender before an acknowl- 

edgment is sent, with an implied modulus for the send and receive sequence 
counts--less than 8 implies a modulus of 8» 8 or greater implies a modulus of 128 

Reserved . 

Control vectors, as described in "Control Vectors" on page B-10 

Note: The following control vectors may be included: 

X'OE' Network Name control vector: type X'F4', network-qualified CP name (always present; the 
network identifier is always used, i.e., valid lengths of the CP name are 3 to 17 bytes 
with an imbedded period) 

X'OE' Network Name control vector: type X'F7', local name of the ALS at the XID sender (always 
present ) 

X'10° Product Set ID control vector (always present) 

Note: When included in XID, the product set ID is limited to 60 bytes or less in length. 

X'22' XID Negotiation Error control vector (conditionally present: present when an error dur- 
ing XID negotiation is detected; more than one may be present) 


REQUEST/RESPONSE UNITS 


BIND; PLU-->SLU, Exp; SC (BIND SESSION) 


= 


BIND is sent from a primary LU to a secondary LU to activate a session between 
the LUs. The secondary LU uses the BIND parameters to help determine whether 


it will respond positively or negatively to BIND. 


X'31' request code 

bits 0-3, format: 0000 (only value defined) 

bits 4-7, type: 
0000 negotiable (only value defined for LU 6.2) 
0001 nonnegotiable 

FM profile: 

X'02' FM profile 2 

X'03' FM profile 3 

X'04' FM profile 4 

X'07' FM profile 7 

X'12' FM profile 18 

X'13' FM profile 19 Conly value defined for LU 6.2) 

TS profile: 

X'02' TS profile 2 
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X'03' TS profile 3 
X'04' TS profile 4% 
X'O7' TS profile 7 Conly value defined for LU 6.2) 


bit 0, 


bit 1; 


“chaining use selection: 

0 only single-RU chains allowed from primary LU half-session 

1 multiple-RU chains allowed from primary LU half-session (only value defined for LU 
6.2) 

request control mode selection: 

0 immediate request mode (only value defined for LU 6.2) 

1 delayed request mode 


bits 2-3, chain response protocol used by primary LU half-session for FMD requests; chains from 


bit 4, 


bit 5, 


bit 6, 


bit 7; 


a a 7 


bit 1, 


primary will ask for: 
00 no response 
Ol exception response 
10 definite response 
11 definite or exception response (only value defined for LU 6.2) 
2-phase commit for syne point (reserved if any TS profile other than 4): 
0 2-phase commit not supported 
1 2-phase commit supported 
reserved 
compression indicator (reserved for LU 6.2): 
0 compression will not be used on requests from primary 
1 compression may be used 
send End Bracket indicator: 
0 primary will not send EB (only value defined for LU 6.2) 
l primary may send EB 
chaining use selection: 
0 only single-RU chains allowed from secondary LU half-session 
1 multiple-RU chains allowed from secondary LU half-session (only value defined for LU 
6.2) 
request control mode selection: 
0 immediate request mode (only value defined for LU 6.2) 
1 delayed request mode 


bits 2-3, chain response protocol used by secondary LU half-session for FMD requests; chains 


bit 4, 


bit 5, 
bit 6» 


bit 7, 


from secondary will ask for: 
00 no response 
01 exception response 
10 definite response 
ll definite or exception response (only value defined for LU 6.2) 
2-phase commit for syne point (reserved if any TS profile other than 4): 
0 2-phase commit not supported 
1 2-pnase commit supported 
reserved | 
compression indicator (reserved for LU 6.2): 
0 compression will not be used on requests from secondary 
1 corpression may be used 
send End Bracket indicator: 
0 secondary will not send EB (only value defined for LU 6.2) 
1 secondary may send EB 


EM Usage—-Common LU Proteccols 


bit 0, 


bit 2, 


bit 3, 


bit 4, 


SNA Format 


whole-BIUs required indicator: 

0 the sending node supports receipt of segments on this session 

1 the sending node does not support receipt of segments on this session; the maximum 
sent-RU size specified in bytes 10 and 11 of BIND and RSP(BIND) are negotiated so 
that BIUs on this session are not segmented when sent to a node requiring whole BIUs 

FM header usage: 

0 FM headers not allowed 

1 FM headers allowed (only value defined for LU 6.2) 

brackets usage and reset state: 

0 brackets not used if neither primary nor secondary will send EB, i.e.» if byte 4, 
bit 7 = 0 and byte 5, bit 7 = 03 brackets are used and bracket state managers’ reset 
states are INB (1) if. either primary or secondary, or both, may send EB, 1.e., if 
byte 4, bit 7 = 1 or byte 5, bit 7 = 13 or (2) if FM profile 19 is specified (only 
value defined for LU 6.2) 

0 brackets are used and bracket state managers’ reset states are INS 

1 brackets are used and bracket state managers’ reset states are BETB 

bracket termination rule selection (reserved if brackets not used, i.e.» if byte 6, 

bit 2 = 0, byte 4» bit 7 = 0, and byte 5, bit 7 = 03 and if FM profile is not 19:: 

0 Rule 2 (unconditional termination) will be used during this session 

1 Rule 1 (conditional termination) will be used during this session (only value defined 
for LU 6.2) 

alternate code set allowed indicator: 
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0 alternate code set will not be used 
1 alternate code set may be used 
bit 5, sequence number availability for syne point resynchronization (reserved if any TS pro- 
file other than 4 1s used): 
0 sequence numbers not available 
1 sequence numbers available 
Note: Sequence numbers are transaction processing program sequence numbers from the 
previous activation of the session with the same session name; they are associated 
with the last acknowledged requests and any pending requests to commit a unit of 
work. If no previous activation existed, the numbers are 0, and this bit is set to 
0. 
bit 6, BIS sent (reserved for TS profiles other than 4): 
0 BIS not sent 
1 BIS sent 
bit 7, BIND queuing indicator: 
0 BIND cannot be queued (held, pending resource availability, thus delaying the BIND 
response ) 
1 BIND sender allows the BIND receiver to queue the BIND for an indefinite period, thus 
delaying the sending of the BIND response 
Note: BIND sender may provide a timer or operator interface to send UNSIND if 
session-activation time exceeds BIND sender's implementation-defined limits. BIND 
queuing 1s terminated by sending UNBIND to the BIND receiver. 
bits 0-1, normal-flow send/receive mode selection: 
00 full-duplex 
01 half-duplex contention 
10 half-duplex flip-flop (only value defined for LU 6.2) 
ll reserved 
bit 2, recovery responsibility (reserved if normal flow send/receitve mode is FDX, i.e., if 
byte 7, bits 0-1 = 00): 
0 contention loser responsible for recovery (see byte 7, bit 3 for specification of 
thich half-session is the contention loser ) 
1 symmetric responsibility for recovery (only value defined for LU 6.2) 
bit 3, contention winner/loser (reserved if normal flow send/receive mode is FDX, i.e.» if 
byte 7, bits O-1 = 00; or if the normal flow send/receive mode is HDX-FF, brackets are 
not used, FM profile is not 19, and symmetric responsibility for recovery is used, 
1.@.>9 1f byte 7, bits 0-1 = 10, byte 4, bit 7 = 0, byte 5, bit 7 = 0, byte 6, 
bit 2 = 0, and byte 7, bit 2 = 1): 
0 secondary is contention winner and primary ts contention loser 
1 primary is contention winner and secondary is contention loser 
Note: Contention winner is also brackets first speaker if brackets are used. 
bits 4-5, alternate code processing identifier (reserved unless Alternate Code Set Allowed 
indicator (byte 6, bit 4) is 1): 
00 process alternate code FMD RUs as ASCII-7 
0! process alternate code FMD RUs as ASCII-8 (only value defined for LU 6.2) 
Note: When the Alternate Code Processing Identifier indicator is set to the value 
01, the entire FMD request RU is to be translated using the transforms defined by the 
ANSI X3.26 Hollerith Card Code. 
bit 6, reserved 
bit 7, half-duplex flip-flop reset states (reserved unless (1) normal-flow send/receive mode 
is half-duplex flip-flop (byte 7, bits 0-1 = 10) and (2) brackets are not used or 
bracket state manager's reset state is INB (byte 6, bit 2 = 0)): 
0 HDX-FF reset state 1s RECEIVE for the primary and SEND for the secondary (e.g., the 
secondary sends normal-flow requests first after session activation). 
! HDX-FF reset state is SEND for the primary and RECEIVE for the secondary (e.g.» the 
primary sends normal-flow requests first after session activation) (only value 
defined for LU 6.2) 
IS Usage 
bit 0, staging indicator for session-level pacing of the secondary-to-primary normal flow: 
0 the secondary send window size (byte 8, bits 2-7) and the primary receive window size 
(byte 13, bits 2-7) are for one-stage pacing (The secondary send window size is 
always equal to the primary receive window size. ) 
1 the secondary send window size (byte 8, bits 2-7) and the primary receive window size 
(byte 13, bits 2-7) are for two-stage pacing 
Note: The meanings of 0 and |! are reversed from the corresponding staging indicator 
for the primary-to-secondary normal flow. 
bit 1, reserved 
bits 2-7, secondary send window size, in binary, for session-level pacing 
bits 0-1, reserved 
bits 2-7, secondary receive window size, in binary, for session-level pacing 
Maximum RU size sent on the normal flow by the secondary half-session: if bit 0 1s set to 0, 
no maximum is specified and the remaining bits 1-7 are ignored; if bit 0 is set to 1, bit 0 Is 
set to !, and the byte is interpreted as X'ab' = a€2%*b (Notice that, by definition, a28 and 
therefore X'ab' is a normalized floating point representation.) See Figure B-1 on page B-8 for 
all possible values. 
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Yl 
12 


13 


14 


15 


16-22 
23 


24 


25 


26-K 
26 
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Maximum RU size sent on the normal flow by the primary half-session: identical encoding as 
described for byte 10 
bit 0, staging indicator for session-level pacing of the primary-to-secondary normal flow: 
0 the primary send window size (byte 12, bits 2-7) and the secondary receive windos 
size (byte 9, bits 2-7) are for two-stage pacing 
1 the primary send window size (byte 12, bits 2-7) and the secondary receive window 
size (byte 9, bits 2-7) are for one-stage pacing (The primary send bi ncions size is 
always equal to the secondary receive window size. ) 
Note: The meanings of 0 and | are reversed from the corresponding staging indicator 
for the secondary-to-primary normal flow (byte 8, bit 0). 
bit 1, reserved — 
bits 2-7, primary send window size, in binary,» for session-level pacing 
bits 0-1, reserved 
bits 2-7, primary receive window size, in binary, for session-level pacing 
PS Profile 
bit 0, PS Usage field format: 
0 basic format (only value defined) 
bits 1-7, LU type: 
0000000 LU type 
0000001 LU type 
0000010 LU type 
0000011 LU type 
0000100 LU type 
0000110 LU type 
0000111 LU type 


NOP OWNY & O&O 


PS Usage characteristics 
Note: The following format for bytes 15-25 applies only to LU 6.2; for information on PS usage 


bytes 15-25 for other than LU 6.2 (indicated by byte 14, bits 1-7 = 0000110 and byte 15 = 
00000010), see SNA—Sessions Between Logical Units. 
LU-6 level: 
X'02' Level 2 (t.e., LU 6.2) 
Reserved 
bits 0-2, retired 
bit 3, conversation-level security support: 
0 Access Security Information field mill not be accepted on incoming FMH-Ss 
1 Access Security Information field will be accepted on incoming FMH-5s 
bits 4-5, reserved 
bit 6, already-verified function support: 
0 Already Verified indicator will not be accepted on incoming FMH-5s 
1 Already Verified indicator will be accepted on incoming FMH-5s 
bit 7, reserved 
bit 0, reserved 
bits 1-2, synchronization level: 
01 confirm is supported 
10 confirm, syne point, and backout are supported 
bit 3, reserved 
bits 4-5, responsibility for session reinitiation (reserved unless bit 6 of this byte 1s er to 
0): 
00 operator controlled 
01 primary half-session will reinitiate 
10 secondary half-session will reint trate 
\l either may reinitiate 
bit 6, parallel session support for LU-LU pair: 
0 not supported 
1 supported 
bit 7, Change Number of Sessions 605 variable flow support (set to 1 if byte 24, bit 6 = 1): 
0 not supported 
1 supported 
Reserved 
End of PS Usage Field 
Cryptography Options 
bits 0-1, private cryptography options (reserved for LU 6.2): 
00 no private cryptography supported 
OL private cryptography supported: the session cryptography an and cryptography 
protocels are privately supplied by the end user 
bits 2-3, session-level cryptography options: 
00 no session-level cryptography supported 
01 session-level selective cryptography supported; all cryptography key management is 
supported by the SSCP and LU; exchange (via +RSP(BIND)) and verification (via CRV) 
of the cryptography session-seed value is supported by the LUs for the session; 
all FMD requests carrying ED are enciphered/deciphered by the TCs 
10 reserved 
11 session-level mandatory cryptography supported; all cryptography key management is 
supported by the SSCP and LU; exchange (via +RSP(BIND)) and verification (via CRV) 
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28-k 
k+l-m 
k+1 
k+2-m 
atl-n 


m+l 


mteenn 
mre 


Note l: 


Note 2: 


BIND 


of the cryptography session-seed value is supported by the LUs for the session; 
all FMD requests are enciphered/deciphered by TC 
Note: Only values 00 and 1! are defined for LU 6.2. 
bits 4-7, session-level cryptography options field length: 
X'O' no session-level cryptography specified; following additional cryptography 
options fields (bytes 27-k) omitted 
X'9' session-level cryptography specified; additional options follow in next nine 
bytes 
bits O-l, session cryptography key encipherment method: 
00 session cryptography key enciphered under SLU master cryptography key using a seed 
value of 0 (only value defined) 
bits 2-4, reserved 
bits 5-7, cryptography cipher method: 
000 block chaining with seed and cipher text feedback, using the Data Encryption 
Standard (DES) algorithm (only value defined) 
Session cryptography key enciphered under secondary LU master cryptography key; an eight-byte 
value that, when deciphered, yields the session cryptography key used for enciphering and deci- 
phering FMD requests 
Primary LU Name Field (always present) 
Length of primary LU name (values | to 17 are valid) 
Note: Value 0 1s retired. 
Primary LU name or, if the secondary LU issued the INIT-SELF (or INIT-OTHER), INIT-SELF, the 
uninterpreted name as carried in that RU (and also in CDINIT for a cross-domatn session) 
User Data Field 
Length of user data 
Note: X'00' = no User Data field present; if unstructured user data present, values 1 to 65 
are valid. 
User data 
User data key: 
X'00° structured subfields follow (only value defined for LU 6.2) 
Note: Individual structured subfields may be omitted entirely. When present, they 
appear in ascending subfield-number order. 


~X'00' first byte of unstructured user data . 


For unstructured user data: 

Remainder of unstructured user data 

For structured user data: 

Structured subfields (For detailed definitions, see SNA Reference Summary. ) 
User Request Correlation Field (present only if carried in INIT from SLU, or if Secondary LU 
name field or control vectors are included) 

Length of user request correlation (URC) field (values 0 to 12 are valid) 
Note: X'00' = no URC present. 

URC: LU-defined identifier (present only 1f carried in INIT from SLU) 
Secondary LU Nane Field (present only for negotiable BINDs) 

Length of secondary LU name (values |! to 17 are valid) 

Note: Value 0 1s retired. 

Secondary LU name 


The length of the BIND RU cannot exceed 256. 


If the last byte of a format 0 request is a length field and that field is 0, that byte may be 


omitted from the BIND request. 
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Mantissa (a) 


A B Cc 9) E F 


Exponent 
(10) (11) (12) (13) (14) (15) 


(b) 


i 
ns 
es 
es 
a eT 
a 
1024 1152 1280 1408 1536 1664 1792 1920 
p88 2048 2304 2560 2816 3072 3328 3584 3840 
a 4096 4608 5129 5632 6144 6656 7168 7680 
cm 


8192 9216 10240 11264 12288 13312 14336 15360 


16384 18432 20480 22528 24576 26624 28672 30720 


Pea 
[easy | astre tree isan iecey risus eve 2m Te | 


Note: A value of X'ab' in byte 10 or byte 11 of BIND represents a*2¥*b. For example, X'C5' 
represents (in decimal) 12°2%*5 = 384. 


Figure B-1. RU Sizes Corresponding to Values X‘'ab' in BIND 
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UNB IND 


UNBIND; LU-->LU, Exp; SC (UNBIND SESSION) 


0 

1 

2-5 
Note lJ: 


UNBIND is sent to deactivate an active session between the two LUs. 


X'32' request code 

UNBIND type (for UNBIND types X'00' through X'06' and X'80' through X'FF', the session is ended 

when the response is received; for UNSIND types X'07' through X'7F', the session is ended imme- 

diately): 

X'O1' normal end of session 

X'02* BIND forthcoming; retain the node resources allocated to this session, if possible 

X'06' invalid session parameters: the BIND negotiation has failed because the primary 
half-session cannot support parameters specified by the secondary 

X'07' virtual route inoperative: the virtual route used by the LU-LU session has become inop- 
erative, thus forcing the deactivation of the identified LU-LU session 

X'08' route extension inoperative: the route extension used by the LU-LU session has become 
inoperative, thus forcing the deactivation of the identified LU-LU session 

X'09' RWierarchical reset: the identified LU-LU session is being deactivated because of a 
+RSP((ACTPU | ACTLU), Cold) 

X'OA' SSCP gene: the identified LU-LU session had to be deactivated because of a forced deac- 
tivation of the SSCP-PU or SSCP-LU session (e.g., DACTPU, DACTLU, or DISCONTACT was 
received) 

X'OB' virtual route deactivated: the identified LU-LU session had to be deactivated because of 
a forced deactivation of the virtual route being used by the LU-LU session 

X'OC' LU failure--umrecoverable: the identified LU-LU session had to be deactivated because of 
an abnormal termination of the PLU or SLU; recovery from the failure was not possible 

X'OE' LU failure--recoverable: the identified LU-LU session had to be deactivated because of 
an abnormal termination of one of the LUs of the session; recovery from the failure may 
be possible 

X'OF' cleanup: the node sending UNBIND is resetting its half-session before receiving the 
response from the partner node 

X'11' gateway node cleanup: a gateway node 1s cleaning up the session because a gateway SSCP 
has directed the gateway node {via NOTIFY) to deactivate the session (e.g., a session 
setup error or session takedown failure has occurred) 

X'FE' session failure: the session has failed for a reason specified by the associated sense 
data 


For UNBINOD Type=X'FE', the Sense Data field is included; otherwise, it 1s omitted. 
Sense data: same value as generated at the time the error was originally detected (e.g., for a 


negative response, receive check, or EXR) 
Extensions to the UNBIND (umrecognized after byte 5) are ignored by receivers at the current 


level of SNA. : 


RSP(BIND)3; SLU-->PLU, Exp; SC 


27 


A +RSP(BIND) carries the session parameters as indicated by the SLU or by 
intermediate nodes along the session path. 


e A short (l-byte) response may be sent for a nonmmegotiable BIND request that 
specifies no session-level cryptography. 

e A cryptography response (bytes 0-k) may be sent for a nonnegotiable BIND 
request that specifies session-level cryptography. 

°¢ A negotiable response (bytes 0O-r) may be sent for a negotiable BIND 
request. | 


X'31' request code 

bits 0-3, format: 0000 (only value defined) 

bits 4-7, type: 
0000 negotiable (only value defined for LU 6.2) 
0001 nonnegotiable 

Bytes 2-25 of the BIND request: for a negotiable response, the negotiated values may differ 

for a cryptography response, the values are the same as those received in the BIND request 

Cryptography Options (see Note 3) 

bits 0-1, private cryptography options: for a nonnegotiable response, same value as received 
in the request, if present 

bits 2-3, session-level cryptography options: for a nonnegotiable response and an LU 6.2 
response, same value returned as received. in the request, if present 

bits 4-7, sessiton-level cryptography options field length: same value (Bytes 27-k are omitted 
if this length field is omitted or set to 0.) 

bits 0-1, session cryptography key encipherment method: same value returned as received in the 
request, if present 

bits 2-4, reserved 

bits 5-7, cryptography cipher method: same value returned as received 
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28-k An eight-byte implementation-chosen, nonzero, pseudo random session-seed cryptography value 
| enciphered under the session cryptography key» if session-level cryptography is specified; oth- 
erpise, omitted 
k+l(=m) Retired: set to 0 by implementations at the current level of SNA 


mel Length of user data 

m+2-n User data: for a negotiable response, the user data may differ from that received on the BIND 
request . . 

n+l Length of URC 

n+2-p URC as received on the BIND request 


p+l(=r) Retired: set to 0 by implementations at the current level of SNA 


Note 1: On a response, if the last byte of a response is a length field and that field is 0, that byte 
may be dropped from the response. This applies also to byte 26 (where the count occupies only bits 4-7) 
if bits 0-3 are also 0—the entire byte may be dropped if no bytes follow. 


Note 2: In negotiable BIND responses, reserved fields in the BIND are set by the SLU to binary 0's in 
the RSP(BIND); any fields at the end of the BIND (after byte r) that are not recognized by the SLU are 
discarded and not returned in the RSP(BIND). 


Note 3: The first byte of the Cryptography Options field (byte 26) is returned on the response for a 
nonnegotiable BIND only when session-level cryptography was specified in the BIND. Byte 26 is always 
present in any negotiable response if not truncated as allowed in Note 1. In all cases, however, the 
remaining bytes of the Cryptography Options field (bytes 27-k) are present only if session-level 
cryptography was specified in the BIND. . 


CONTROL VECTORS 


Preduct Set ID (X'10') 


0 Key: X'10' 

1 Length (n-1), in binary, of Vector Date field 

e-n Vector Data 

2 Retired 

3-n Network product identifier: one or two Product Identifier (X'1l1') MS common subvectors, as 


described in SNA Reference Summary, one for each hardware product and software product in the 
implementation 1 of the PU 


Network Name (X'OE' ) 


0 Key: X‘OE' 

1 Length (n-1), in binary, of Vector Data field 
e-n Vector Data 

2 Network name type: 


X'F4' CP name 
X'F7' link station name (not network-quali fied) 

3-n Network-qualified name: a l- to 17-byte name consisting of an optional qualifier concatenated 
to a l- to 8-byte type-A symbol-string name; when present, the qualifier contains a Il- to 
8-byte type-A symbol-string network identifier concatenated with a pertod (mhen the qualifier 
is not present, the pertod 1s omitted). The network-qualified name appears, for example, as 
follows: NETIO.NAME, with no imbedded blanks and with optional (but not significant) trailing 
blanks. 


XID Negotiation Error (X%'22') 


0 Key: xX‘'22° 

1 Length (n-1), in binary, of Vector Data field 

e-n Vector Data 

2-3 Error byte offset: the binary offset (zero-origin in the XID information field) of the first 
‘byte of the field tn error 

4(=n) Error bit offset: the binary offset (zero-origin in the byte pointed at in the Error Byte Off- 

set field) of the first bit of the field in error 
SENSE DATA 


The sense data included with an EXCEPTION REQUEST (EXR), a negative response, or an UNBIND request, is a 
four-byte field (see Figure B-2 on page B-11) that includes a one-byte category value, a one-byte modi fi- 
er value» and two bytes of sense code specific information, whose format 1s defined along with the sense 
code definition, below. | 
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RSP( BIND) 


iol Be ol Bea Bl 


_ 


< 


Sense-code ree 
information 


Sense Code———> 


<——_——__—___—_—_——-Sense Data————________— 
Figure B-2. Sense Data Format 
Together, the category byte 0, the modifier byte 1, and the sense code specific bytes 2 and 3 hold the 


sense data defined for the exception condition that has occurred. 


The followtng categories are defined; all others are reserved: 


VALUE CATEGORY 

X'o0a' Recuest Reject 

X'10° Request Error 

Xx'20' State Error 

X°'4Q0' Request Header (RH) Usage Error 
x'80' Path Error 


In earlier versions of SNA, user data (as well as implementation-specific data) generally could be car- 
ried in bytes 2-3 for all categories. This is no longer the case. Bytes 2-3 are used generally only for 
SNA-defined conditions for nonzero categories; exceptions for implementation-specific use are documented 
in the appropriate product publications. 


The sense codes for the other categories are discussed belos. 


This category indicates that the request was delivered to the intended component and was understood and 
supported, but not executed. 


Category and modifier (in hexadecimal): 


0801 Resource Not Available: The LU, PU, link station, or link specified in an RU is not available. 
0812 Insufficient Resource: Receiver cannot act on the request because of a temporary lack of 
resources. 


Bytes 2 and 3 may contain the following sense code specific information: 
0000 No specific code applies. 

0007 Insufficient resources are available for LU address allocation. 
0000 Insufficient buffers exist to activate a session. 


0815 Function Active: A request to activate a netvork element or procedure was received, but the 
element or procedure was already active. 


Bytes 2 and 3 following the sense code contain sense code specific information: 


0004 A BIND was received from an T2.1 node when the session is already active; i.e., the LFSID 
is in use. The receiver rejects the BIND. 
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0835 Invalid Parameter (with Pointer Only): The request contained a fixed- or variable-length field 
whose contents are invalid or not supported by the NAU that received the request. 


nnnn Bytes 2 and 3 contain a two-byte binary count that indexes (zero-origin) the first byte 
of the fixed- or variable-length field having invalid contents. 


REQUEST ERROR (CATEGORY CODE = X'10')} 


ES EEE = EEE = EG AEE 


This category indicates that the RU was delivered to the intended NAU component, but could not be inter- 
preted or processed. This condition represents a mismatch of NAU capabilities. 


Category and modifier (in hexadecimal ): 


1002 RU Length Error: The request RU was too long or too short. 


This category indicates that the value of a field or combination of fields in the RH violates architec- 
tural rules or previously selected BIND options. These errors prevent delivery of the request to the 
intended component and are independent of the current states of the session. They may result from the 
failure of the sender to enforce session rules. Detection by the receiver of each of these errors is 
optional. 

Category and modifier (in hexadecimal): 


4005 Incomplete RH: Transmission shorter than full TH-RH. 


Te ie CED | EE | ED 


This category indicates that the request could not be delivered to the intended receiver, because of a 
path outage, an invalid sequence of activation requests, or one of the listed path information unit (PIU) 
errors. Some PIU errors fall into other categories; for example, sequence number errors are sense code 
category X'20'. A path error received while the session is active generally indicates that the path to 
the session partner has been lost. ' 

Category and modifier (in hexadecimal): 


8004 Unrecognized Destination: A nede in the path has no routing information for the destination 
specified either by the SLU name in a BIND request or by the TH. 


8005 No Session: No half-session is active in the receiving end node for the indicated 
origination-destination pair, or no boundary function session connector is active for the 
origin-destination pair in a nede providing the boundary function. <A session activation 
request is needed. : 

8006 Invalid FID: Invalid FID for the receiving node. 


8007 Segmenting Error: First BIU segment had less than 10 bytes; or mapping field sequencing error, 
such as first, last, middle; or segmenting not supported and MPF not set to ll. 


Bytes 2 and 3 following the sense code contain sense code specific information: 
0000 No specific code applies. 


0001 The node does not support receipt of segments; and a mapping field value other than OIS 
was received. Sent in UNBIND. 


800B Incomplete TH: Transmission received was shorter than a TH. 
800F The address combination is invalid. . 
Bytes 2 and 3 following the sense code contain sense code specific information: 
0000 The (DAF',OAF') (FID2) combination or the LSID (FID3) specified an invalid type of ses- 


Sion, for example, a PU-LU combination. 
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0001 The FID2 ODAI setting in a received BIND is incorrect; the BIND is rejected. 
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APPENDIX C. JERMINOLOGY: ACRONYMS ANO ABBREVIATIONS 


Replace this page with foldout page C-1 from the back of the book. 
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C-2 T2.1 Node EFAP 


Replace this page with foldout page C-3 from the back of the book. 
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C-4 2.1 Node EFAP 


— 


<< 


SPECIAL CHARACTERS 


{period), to separate name qualifiers A-1 
. (underscore), in name phrases A-] 
# (pound sign), to indicate generic FSM A-1 


ABM 


See asynchronous balanced mode (ABM) 
ABME 
See asynchronous balanced mode extended 
( ABME ) 
activation 
See finite-state machine (FSM) 
See link activation 
address space 1-1 
See also local-form session identifier 
(LFSID) 
definition l-1 
management 3-1 
address space manager (ASM) 1-6, 
See also control point (CP) 
adjacent link station (ALS) 1-1 
ALS 


3-1 


See adjacent link station (ALS) 
ASM 
See address space manager (ASM) 
asynchronous balanced mode (ABM) 
role considerations for 2-8 
asynchronous balanced mode extended 
(ABME) 2-3, 2-5 


basic information unit (BIU) 1-6, 
basic link umit (BLU) Il-1, 2-12 
basic transmission unit (BTU) 1-2, 1-6> 
2-14, 4-2 _ 0 
base maximum Stz 
routing to LUs 4-2 
transmission between nodes 4-2 
BIND 1-2, 1-3, 1-6, 2-9, 3-1, 3-2, G-2, G-4, 
B-1, B-3 
See also BIND SESSION 
BIND SESSION (BIND) B-3 
BIU 
See basic information unit (BIU) 
BLU 
See basic link wmit (BLU) 
BTU 
See basic transmission unit (BTU) 


2-3, 2-5 


4-2 


4-4 


i 


category value, sense code B-10 
See also sense data 
CCITT recommendation V.27-ter 2-6 
COMMAND_RESFONSE_RCV_INDICATOR struc- 
ture 2-36 
referenced by 
FSM_XID3_T2P1_NODE 2-18 
configuration services (CS) 1-6, 
See also control point (CP) 
control point (CP) 1-46, 1-5 
See also address space manager (ASM) 
See also configuration services (CS) 
See also session services (SS) 
control vector 2-14 


2-1 


Negotiation Error X‘'22' 2-14, B-10 

Network Name X'OE', type X'F7' (Adjacent 
Link Station Name) 2-14, B-10 

Network Name, type X'F4' (CP Name) 2-9, 
2-14, B-10 

Product Set ID X'10' 2-14, B-10 


Cp 
See control point (CP) 
current level of SNA 
definition 2-4 


Pe 


DAF’ 
See Destination Address field prime (DAF') 
data link control (DLC) I-2, 1-4, 1-6, 2-5; 
2-11, 2-15 | 
See also asynchronous balanced mode (ABM) 
See also asynchronous balanced mode 
extended (ABME ) 
See also normal response mode (NRM) 
See also normal response mode extended 


(NRHE ) 
responsibilities during link acti- 
vation 2-5 
rules for ABM link stations 2-6 
rules for NRM link stations 2-5 


Destination Address field prime (DAF') 
4-2 
See also format identification type 2 
(FID?) 
See also local-form session identifier 
(LFSID) 
DISC 
See Disconnect (DISC) 
Disconnect (DISC) 2-3 
Disconnect Mode (DM) 
DLC 
See data link control (DLC) 


1-1; 


2-5, 2-15 


OM 


See Disconnect Mode (DM) 


Index 


G 


ELLC 
See enhanced logical Link control (ELLC) 
enhanced logical link control (ELLC) 2-14 
equalization, modem 
See modem equalization 
error category 
See sense data 
errors | 
See also control vector 
address space manager (ASM) 3-2 
modulus resolution 2-14 
path control (PC) 4-4 
reporting of 2-14 
XID3 exchange 2-14 
ESI 
See Exchange State indicators (ESI) 
EXCEPTION REQUEST (EXR) 3-2; 4-3 . 
Exchange Identification command (XID) IL-1, 
e-3, 2-12 
See also Exchange Identification command 
format 3 (XID3) 
collision avoidance 2-6 
general rules for exchange of 2-7, 2-15 
null 2-3 
sequencing 2-7 
Exchange Identification command format 3 
(XID3) 1-2, 2-3, 2-12 
See also errors 
See also Exchange Identification command 
(XID) 
ABM Support indicator 2-12 
errors 2-14 
I-field 1-1, 2-6, 2-7») 2-12 
Link Station Role of the XID Sender 
field 2-12 
Maximum Number of I-Frames field 2-13 
negotiation-proceeding exchange 2-3, 2-8 
Node Identification field 2-8, 2-12, 2-14 
Block Number field 2-8), 2-12 
ID Number field 2-8), 2-12 
randomization of 2-8 
nonactivation exchange 2-3, 2-7, 2-9 
finite-state machines 2-29 
prenegotiation exchange 2-3, 2-7; 2-8 
role negotiation 1-2 
segmenting parameters 4-4 
Exchange State indicators (ESI) 2-1, 2-3, 
2-7, 2-9, 2-14 
EXR ee 
See EXCEPTION REQUEST (EXR) 
EXR (EXCEPTION REQUEST) 
sense data included with 8-10 


i 


FID2 

See format identification type 2 (FID2) 
finite-state machine (FSM) I-1, 2-15 
activation 2-15 

nonactivation 2-29 

notation A-1 
format identification type 2 (FID2) 1-1, 
1-3, 4-2 ? G-4 

See also transmission header (TH) 
FSM 


See finite-state machine (FSM) 
FSM_XID3_NACT_PRI 2-31 
FSM_XID3_NACT_SEC 2-33 
FSM_XID3_NEG_PROTOCOL 2-21 
FSM_XID3_NEG_PROTOCOL FSM 

referenced by 

FSM_XID3_T2P1_NODE 2-18 
FSM_XID3_PRI_PROTOCOL 2-25 
FSM_XID3_PRI_PROTOCOL FSM 

referenced by 

FSM_XID3_T2P1_ NODE 2-18 
FSM_XID3_SEC_ PROTOCOL 2-27 
FSM_XID3_SEC_PROTOCOL FSM 
referenced by 

FSM_XID3_T2P1_NODE 2-18 
FSM_XID3_T2P1_NODE 2-17 


[s | 


generic FSM A-1 


[*] 


half-session 4-2 
See also logical unit (LU) 


i 


I-frame 2-11, 2-14 
I-frames, maximum number of B-3 
initial program load (IPL) 1-5 
IPL 

See initial program load (IPL) 


LFSID 
See local-form session identifier (LFSID) 
link 1-1, 1-2 
link activation Il-1, 1-6), 2-3, 2-5 
‘finite-state machines 2-15 
phases 2-1, 2-3 
link connection I-1,; 2-4 
link deactivation 1-6, 2-3, 2-11 
link station role 2-3, 2-4, 2-5, 2-6, 2-8» 
2-12, 2-14, 2-15. 
negotiation of 2-8 
links, multiple 1-2 
local-form session identifier (LFSID) I-11, 
1-6, 4-2 
See also address space manager (ASM) 
address assignment 3-1! 
composition 3-1 
logical unit (LU) jit, l-1, 1-4, 1-5 
See also half-session 
LU 
See logical umit (LU) 
LU 6.2 
See logical unit (LU) 
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Mapping field (MPF) 4-3 
mode-setting command 2-3, 2-5, 2-29 
See also normal response mode (NRM) 
See also normal response mode extended 
(NRME ) 
See also Set Normal Response Mode (SNRM) 
See also Set Normal Response Mode Extended 
(SNRHE ) 
modem equalization 2-3, 2-4, 2-6 
rules for 2-7 
modifier value, sense code 6-10 
See also sense data 
modulus resolution 2-13 
errors 2-14 
token-ring considerations 2-13 
MPF 
See Mapping field (MFF) 
multipoint Link connections 2-4 
multipoint-capable connections 2-4 


NAU 

See network addressable unit (NAU) 
negative response 

sense data included with B-10 
negotiation 

See Exchange Identification command forma 

3 (XID3) 3 

See link station role 
network addressable wit (NAU) 1-6 
Network Name (X'0E') B-10 

See also control vector 
Network Services SLU Name 3-2 
nodal NAU manager 1-6 
node operator facility (NOF) 1-4, 1-5 
NOF 

See node operator facility (NOF) 
NONACT_XID_EXCHANGED structure 2-36 

referenced by 

FSM_XID3_NACT_PRI 2-31 
FSM_XID3_NACT_SEC 2-33 
nonactivation 
See Exchange Identification command format 
3 (XID3) 

See finite-state machine (FSM) | 
normal response mode (NRM) 2-5, 2-11 
normal response mode extended (NRME) 2-5 
NRM 

See normal response mode (NRM) 

NRME 

See normal response mode extended (NRME) 
null XID | 

See Exchange Identification command (XID) 

See polling 


a 


OAF ' 
See Origin Address field prime (OAF') 
OAF'-DAF' Assignor indicator (ODAI) Il-lI, 
2-8, 3-1, 4-2 
See also format identification type 2 
(FID2) 


See also local-form session identifier 
(LFSID) 
ODAI 
See OAF'-DAF' Assignor indicator (ODAI) 
Origin Address field prime (OAF') 1i-1, 4-2 
See also format identification type 2 
(FID2 ) 
See also local-form session identifier 
(LFSID) 


i 


path control (PC) I-1, 1-3, 1-4, 1-6, 3-1, 
4-1 
path control instance 
See path control (PC) 
path information umit (PIU) 4-2 
PC 
See path control (PC) 
peer connection 1-1 
PIU 
See path information unit (PIU) 
PLU 
See primary logical unit (PLU) 
polling 2-3, 2-5, 2-6, 2-15 
primary logical unit (PLU) 1-2 
See also secondary logical unit (SLU) 
primary-secondary roles 
See link station role 
Product Set ID (X'10') B-10 
See also control vector 


[e 


QLLC 
See qualified logical link control (QLLC) 
qualified logical link control (QLLC) 2-14 


[e 


See Request Disconnect (RD) 
Receive Not Ready (RNR) 2-3, 2-11 
RECVD_XID structure 2-37 

referenced by 

FSM_XID3_T2P1_ NODE 2-18 

Request Disconnect (RD) 2-3, 2-11 
Request Response (RR) 2-3 
request/response heacer (RH) 4-3, 4-4 

See also request/response unit (RU) 
request/response unit (RU) 1-3, 4-4 

See also request/response header (RH) 
RH 

See request/response header (RH) 
RNR 

See Receive Not Ready (RNR) 
route outage 3-2 
routing 

LU to PC 3-1 

non-session traffic 3-1] 

PC to LU 3-2 
RR 

See Request Response (RR) 
RSP(BIND) 1-3, 1-6, 3-2, 4-3, B-1l, B-9 
RSP(UNBIND) 1-3, 1-6, 3-2, B-l 


Index X-3 


RU 
See request/response unit (RU) 
SABM 
See Set Asynchronous Balanced Mode (SABM) 
SABME | 
See Set Asynchronous Balanced Mode 
Extended (SABME ) 
SOLC 
See Synchronous Data Link Control (SOLC) 
secondary logical unit (SLU) 1-2 
See also primary logical unit (PLU) 
segmenting 
parameters 4-4 
segment generation 4-2, 4-3 
segment reassembly 4-2, 4-4 
support of 4-3 
SEND_RECEIVE_DIRECTION structure 2-36 
referenced by 
FSM_XID3_NEG PROTOCOL 2-22 
--« FSM_XID3_T2PI1_NODE 2-18 
SEND_XID structure 2-36 
referenced by 
FSM_XID3_NACT_PRI 2-31 
FSM_XID3_NACT_SEC 2-33 
FSM_XID3_NEG_PROTOCOL 2-22 
FSM_XID3_PRI_PROTOCOL 2-25 
FSM_XID3_SEC_PROTOCOL 2-27 
FSM_XID3_T2PI_NODE 2-18 
sense code 
See sense data 
sense data B-10 


format of B-10 
sense code 


category X'08' (request reject) B-10, 
B-11 : 

category X'10' (request error) B-10, 
B-12 

category X'20' (state error) B-10 

category X'40' (RH usage error) 5-10, 


B-le 


category X'80' (path error) B-10, 8-12 


modifier B-10 
sense-code specific information B-10 
session identifier high (SIDH) 3-1, 4-2 
See also local-form session identifier 
(LFSID) : 
session identifier low (SIOL) 3-1, 4-2 
See also local-form session identifier 
(LFSID) 
session initiation capabilities 1-2 
session services (SS) 1-6 | 
See also address space manager (ASM) 
Set Asynchronous Balanced Mode (SABM) 2-8, 
2-12 . 
Set Asynchronous Balanced Mode Extended 
(SABME) 2-8, 2-12 
Set Normal Response Mode (SNRM) 
Set Normal Response Mode Extended 
(SNRME) 2-12 
SIDH © . 
See session identifier high (SIDH) 
SIDL 
See session identifier low (SIDL) 
SNA 


2-12 


See Systems Network Architecture (SNA) 
SNRM 
See Set Normal Response Mode (SNRM) 


SNRME 


ss 


See Set Normal Response Mode Extended 
( SNRME ) 


See session services (55) 


station role 


See link station role 


Synchronous Data Link Control (SOLC) iii, 


1- 
sys 
Sys 


TH 


tok 
tra 


typ 
typ 
T2. 


‘UA 


UNS 
B- 


2s 2-tl 
tem definition 1-3, 2-4, 4-4 
tems Network Architecture (SNA) 


See transmission header (TH) 

en-ring iii, 1-2, 2-65 2-13 
nsmission header (TH) l-1, 4-2) 4-4 
See also format identification type 2 

(FID2) 

e 2.0 (T2.90) 
e 2.1 (T2.1) 
l 

See type 2.1 (T2.1) 


[e | 


See Unnumbered Acknowledgment (UA) 

IND 1-3, 1-6, 3-1) 3-2) 4-3, 4-5, Bel, 
9 

See also UNBIND SESSION 

sense data included with B-10 


ivi, I] 


Vii, L-l, 1-3 
iii,» I-1 


UNBIND SESSION (UNBIND) B-9 


Unnumbered Acknowledgment (UA) 


2-11 


4 


Whole-BIUs Required indicator (in BIND) 4-4 


xX.2 


XID 


XID 


ki 


S§ tits 1-2, 2-3, 2-7 

See also enhanced logical link control 
(ELLC) 

See also qualified logical link control 
(QLLC) 


See Exchange Identification command (XID) 
exchange 

See Exchange Identification command format 
3 (XID3) | 


XID negotiation 


XID Negotiation Error (X‘'22') 


XID 


See Exchange Identification command format 
3 (XID3) 

B-10 

See also control vector 

3 

See Exchange Identification command format 
3 (XI03) 
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APPENDIX C. TERMINOLOGY: 


ABME 
ALS 


ASM 


BIU 
BLU 


BYU 


CP 


cs 


DAF ° 
dIsc 
DLC 


OM 


ACRONYMS AND ABBREVIATIONS 


asynchronous balanced mode 
asynchronous balanced mode extended 
adjacent link station 


address space manager 


basic information unit 
basic link unit 


basic transmission unit 


control point 


configuration services 


Destination Address field prime 
Disconnect (SOLC command) 
data link control 


Disconnected Mode (SDLC response) 


Appendix C. 


EST 


EXR 


ELLC 


FID2 


FRMR 


FSM 


IPL 


LFSID 


LU 


MPF 


NAU 


NOF 


NRM 


Terminology: 


Exchange State indicators 


EXCEPTION REQUEST 


enhanced logical link control 


format identification type 2 


Frame Reject (SOLC response) 


finite-state machine 


initial program load 


local-form session identifier 


logical unit 


Mapping field 


network addressable unit 


node operator facility 


normal response mode 


Acronyms and Abbreviations C-) 


NRME 


OAF ° 


ODATI 


PIU 


PLU 


QLLC 


RO 


RH 


RIM 


RNR 


RR 


RU 


SABM 


normal response mode extended 


Origin Address field prime 


OAF'-DAF® Assignor indicator 


path control 


path information unit 


primary logical unit 


qualified logical link control 


Request Disconnect (SDLC response) 


request/response header 


Request Initialization Mode (SOLC 


response) 


Receive Not Ready (SDLC com- 
mand/response ) 
Receive Ready (SDLC com= 
mand/response ) 
request/response unit 

Mode 


Set Asynchronous Balanced 


(SOLC command) 


Appendix C. 


SABME 


SOLC 


SIDH 


SIOL 


SLU 


SNA 


SNRM 


SHRME 


SS 


TH 


T2.1 


UA 


XID 


XID3 


Terminology: 


Set Asynchronous Balanced Mode 


Extended (SDLC command) 
Synchronous Data Link Control 
session identifier high 
session identifier low 
secondary logical unit 
Systems Network Architecture 


Set Normal Response Moce (SOLC con- 


mand ) 


Set Normal Response Mode Extended 


(SOLC command } 


session services 


transmission header 


type 2.1 


Unnumbered Acknowledgment (SDLC 


response ) 
Exchange Identification (SLDC com- 
mand/response ) 


XID format 3 
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